svn rev #23376: trunk/src/include/

[John Hascall]

> On Mon, 2009-11-30 at 00:25 -0500, Ken Raeburn wrote:
> > This is not the only change recently that assumes that malloc and  
> > friends will never return NULL in a success case; k5-int.h:k5alloc  
> > makes that assumption too.  Are you assuming that the krb5 code will  
> > never make a call requesting zero bytes?  (Or asserting that it  
> > shouldn't and any such cases are bugs; or actually checking the call  
> > sites?)  Or is this just an oversight?

> In general I am happy to assume that krb5 code will never need to
> allocate zero bytes.  This might be foolish, but I have yet to see a
> counterexample.

> As long as it holds, it's a useful simplifying assumption.  In
> particular, I think we might start seeing spurious Coverity defects if
> we start hedging the (ptr == NULL) checks.

   If a zero byte request is a not reasonable one,
   should it be checked for? (in an assert?)

   If a zero byte request is a reasonable one,
   then something like:

      if (bytes == 0) return KRB5_SOME_SUCCESS_CODE;
      ptr = malloc(bytes);
      if (ptr == NULL) return KRB5_SOME_ERROR_CODE;

   would surely pass muster with Coverity.  What I would
   think you want to worry about would be to hide<1> the fact
   that some mallocs return NULL and some return a pointer
   to a "0-byte region" upon a 0-byte request.  Conceivably
   this could lead to memory leaks if the former is
   assumed and the later is true.
   As in:
      ptr = malloc(bytes);
      if (ptr == NULL) {
          return (bytes == 0) ? KRB5_SOME_SUCCESS_CODE : KRB5_SOME_ERROR_CODE;
      }
      /* could have a pointer to zero bytes here */

   ----------
   <1> while I would think that you would always want to return
       nothing given a zero-byte request, I have seen the opposite
       approach to avoiding the uncertainty:
          ptr = malloc(bytes ? bytes : 1);

John