|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Nathaniel McCallum <npmccallum@redhat.com> To: Greg Hudson <ghudson@mit.edu> Date: Tue, 23 Aug 2011 12:13:20 -0400 In-Reply-To: <1314052382.28454.14.camel@t410> Message-ID: <1314116002.27040.3.camel@localhost> Mime-Version: 1.0 Cc: Ken Raeburn <raeburn@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: krbdev-bounces@mit.edu On Mon, 2011-08-22 at 18:33 -0400, Greg Hudson wrote: > On Sat, 2011-08-20 at 15:48 -0400, Ken Raeburn wrote: > > I've always liked that (except for the com_err mess), but I've always > > expected that eventually the external dependencies would have to > > become more advanced. It took us quite a while to start demanding C89 > > support, and after more than a decade we don't require C99. > > MSVC doesn't implement very much of C99, so requiring C99 would mean > switching to MinGW for the core Windows build. I don't know exactly > what the implications of that are since we generate DLLs and wouldn't > want to require DLL consumers to use MinGW as well. > http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs suggests that at a minimum > we'd need to use a Microsoft tool to generate a lib file usable by MSVC. > If that's the end of it then it might be okay (although requiring the MS > SDK in addition to MinGW sounds a little annoying), but converting would > still be a lot of work. MSVC supports a handy subset of C99, including intermixing declarations and code and stdbool. It might be worth permitting just those features which MSVC supports. FWIW, I hate coding without this great C99 pattern: for (int i=0 ; i < max ; i++) ... Nathaniel _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |