Proposed platform assumption changes

[Chris Hecker]

> 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.

I find it surprising that a lot of people chiming in are so willing to
give up the currently working build support for one of the (admittedly
sadly) most used compilers in the world in exchange for pretty minor
syntactic sugar.  Seems crazy to me, but I guess I'm biased as one of
the (apparently) few windows developers who builds krb5 instead of just
links to prebuilt binaries.  However, even if I did just link to it,
I've found (and reported) a bunch of minor bugs, and so fixing those
locally with the proposed mingw way to get designated initializers would
require a completely different toolchain.  Just doesn't seem worth it
for this minor of a win.

Chris



On 2012/01/31 14:28, 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.
> 
>> 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.
> 
> Ken
> 
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev