Little conveniences

[Ken Raeburn]

On Oct 5, 2009, at 03:05, Danilo Almeida wrote:
> My understanding is that this is part of the internal API, so there  
> is no
> ABI concern.  If there were, I would want an allocation function.   
> But in
> that case, I would just have a k5alloc_zero() or something like that  
> and
> then have k5alloc() just be a macro on top of that.  As I see it,  
> the macro
> is simply a convenience on top of the raw API.  Also, since this  
> would only
> be present in the internal headers, it would not introduce any  
> changes to
> the public API.  Not being aware of any other issues, I would  
> certainly vote
> for the consistency of having a krb5 error returned ask making the  
> using
> code simpler.

Where the current "spec" seems to require checking the error code on  
each call, and the style guide doesn't allow such constructs as

   if ((ptr = k5alloc(sz, &err)) == NULL && sz > 0)
     return err;

anyways, I'm not sure it matters much in terms of convenience.  But  
returning the pointer is consistent too -- with system allocation  
routines we're mimicking.  I don't see a strong argument either way.   
I guess my preference would be very mildly in favor of returning the  
pointer, though I think there's also a performance argument to be made  
for returning the error code.  I'm more concerned about the zero-size- 
allocation issue I brought up before...

If you're considering going with forms that require macros, you might  
consider taking it a bit further:

   #define k5new(TYPE,NUM,ERR) ((TYPE  
*)k5calloc(NUM,sizeof(TYPE),&(ERR)))

(or the error-code-returning equivalent), similar to C++'s new[]  
operator.  (With the hypothetical "k5calloc" doing overflow checking,  
zero-size checking, etc.)  The size specifications will usually  
involve "sizeof" anyways when you're not allocating a buffer of bytes  
or a string, and providing the type rather than its size adds to type  
safety checking at compile time via the cast.  Some types like  
krb5_data and krb5_keyblock encapsulate buffers without fixed sizes,  
but helper functions/macros can create those fully initialized while  
hiding the signedness specification headaches of the internal buffer  
pointer types; k5buf and strdup deal with a lot of the string and  
buffer manipulations.

Ken