Proposed platform assumption changes

Nico Williams nico at
Fri Jan 27 20:58:08 EST 2012

On Fri, Jan 27, 2012 at 5:55 PM,  <ghudson at> wrote:
> * I also considered proposing an aborting malloc wrapper.  Platforms
>  generally respond to out-of-memory conditions by killing processes,
>  not returning null from malloc(), and checking for malloc failures
>  adds an extraordinary amount of failure handling logic to our code,
>  which again is difficult to test.  However, Kerberos code is
>  sometimes used in kernels or in embedded environments, and I'm
>  reluctant to make a change which might prevent it from being used
>  there.

Solaris does not have an OOM killer; its malloc() can (and does)
return NULL in memory pressure conditions.

What I recommend is that you have an xmalloc() that is a simple
#define xmalloc malloc on Linux and a function on Solaris that
abort()s when ENOMEM.  In kernels this might be a simple alias of the
kernel allocator.

(In the Solaris kernel the allocator's free() equivalent requires the
allocation size as an argument, FYI.)

> * Named structure initializers appear to be a favorite C99 feature;

Very much so.  They make browsing source code with cscope and friends
much, *much* easier.

>  we've had three separate cases in the past year of people submitting
>  code using them and having to ask for it to be changed.
>  Unfortunately, it's not supported in MSVC, and there's no pretty way
>  of wrapping them to make it work there.  We could consider changing
>  our Windows build to use mingw, but that would be a lot of work and
>  might present other issues.

Is there no way to use a macro for this?  But yeah, this shortcoming
of MSVC is extremely painful.  (I'm acquainted with this problem from
tangentially dealing with a port to Windows of a product that uses
named structure initializers extensively, as well as GCC

Besides helping code browsing, named structure initializers also help
with correctness -- any macro wrapper should probably come with a
script to check correctness when the compiler does not support this


More information about the krbdev mailing list