Proposed platform assumption changes

Simo Sorce simo at
Tue Jan 31 17:56:28 EST 2012

On Tue, 2012-01-31 at 17:28 -0500, Ken Raeburn wrote:
> On Jan 28, 2012, at 12:51, Danilo Almeida wrote:
> > 1) aborting malloc: I am opposed to this change.  By having malloc
> abort, it makes any process using krb5 unable to deal with memory
> pressure.  It is not universally acceptable to force processes to
> abort just because of memory pressure.
> I agree with this.  Checking for allocation failures in N different
> places and freeing up all the right stuff in each one is a pain, but
> this easy out isn't always going to be acceptable.

This pain can be greatly alleviated by using a hierarchical allocator
like talloc. But doing that in the current code base would mean *a lot*
of changes.

> > 2) field initializers: I think that it is important for krb5 to keep
> supporting MSVC.  I would defer changing this until MS releases a
> compiler w/support for this.  (I am not sure as to the current status
> and future support for this from MS.  I know that they had some post
> w/changes in the next compiler (to be released this year, IIRC), but I
> did not find it.)
> How many years have we been waiting so far?  How many more should we
> wait before giving up on them in exasperation?  I believe I read
> somewhere some Q&A or something from Microsoft where they said that
> they were adding support for things their customers wanted, either C99
> features or equivalent functionality -- where the latter means it
> still may not be C99 compliant when they get done with it.
> The 2011 C standard has been published, and we're still waiting for
> the 12-year-old spec to get implemented?  Are there any other major
> platforms that don't have complete or nearly-complete C99 support
> these days?
> I think Sam's right: There are certain requirements for the libraries
> we produce, but that doesn't necessarily imply that MSVC has to be
> useable for building them.  It's probably time to reevaluate the
> options again.



Simo Sorce * Red Hat, Inc * New York

More information about the krbdev mailing list