Proposed platform assumption changes

[Greg Hudson]

Summarizing this thread and the likely outcomes:

* No one voiced concerns about assuming IPv6, variadic macros, and
failure-free mutex locking and unlocking.  So I think we're likely to
assume those.

* No one raised concerns about assuming POSIX signal support in Unix
code, although it's worth noting that Windows has signal() but not
sigaction().  It turns out we don't install signal handlers in any code
built on Windows at the moment, so I think we're likely to assume POSIX
signal support.

* Sam raised concerns about linking against -lpthread from libkrb5 as
opposed to using weak references.  No one raised concerns about simply
removing the ENABLE_THREADS conditional, although the small amount of
code saved may not be not worth it.  So I don't think we'll make any
changes there.

* The idea of using an aborting malloc wrapper inside library code is
objectionable.

* People would really like C99 designated initializers, but the ways of
getting them (dumping MSVC) or sort of getting them (ugly macros) are
objectionable.

On 01/27/2012 06:55 PM, ghudson at MIT.EDU wrote:
> I'd like to propose some changes to the platform assumptions we make
> for the krb5 code base.  In short:
> 
> * Assume POSIX signal support
> * Assume IPv6 support
> * Assume C99 variadic macro support
> * Assume threading support (POSIX or Windows)
> * Assume mutex unlocking can't fail
> * Assume mutex locking can't fail
> 
> Here's some longer discussion of the above and other possible changes:
> 
> * POSIX signals, IPv6, and thread support have become ubiquitous on
>   platforms people are likely to build krb5 on.  We can reduce
>   complexity (particularly in network code by assuming IPv6) by
>   assuming these features.
> 
> * We don't have a lot of uses for variadic macros, but we do have a
>   few (like the macros in k5-trace.h), and they've already crept into
>   the code base a bit.  It's one of the few C99 features supported by
>   MSVC.
> 
> * It's basically impossible to recover gracefully from failure to
>   unlock a mutex.  In practice, I think mutex unlocking generally
>   can't fail except due to programmer error (unlocking a mutex you
>   don't own).
> 
> * Having to check for mutex lock failures adds a lot of failure
>   handling logic which is difficult to test and probably unnecessary.
>   The only practical case I'm aware of where a mutex lock can fail is
>   if you try to lock a recursive mutex too many times, but the
>   k5_mutex abstraction doesn't support recursive mutexes anyway (when
>   we need them we build our own wrapper).
> 
> * 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.
> 
> * Named structure initializers appear to be a favorite C99 feature;
>   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.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev