Little conveniences

Danilo Almeida dalmeida at MIT.EDU
Mon Oct 5 03:05:45 EDT 2009


> I'm a little reluctant to introduce a construction which can only be
> defined as a macro, but if people think it's worth that price to keep
> the order consistent, I'll switch it around.

I'm curious, what is your concern?

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.

- Danilo

More information about the krbdev mailing list