Hi, > -----Original Message----- > From: morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] On Behalf > Of Levi Morrison > Sent: Saturday, November 12, 2016 9:47 PM > To: Dennis Clarke <dcla...@blastwave.org> > Cc: internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] C89 vs. C99 > > On Sat, Nov 12, 2016 at 1:37 PM, Dennis Clarke <dcla...@blastwave.org> > wrote: > > > >> IMHO, if we decide to move to C99, we should do it the strict way > > > > > > I forgot to add that GNU GCC allows a lot of non-standard extensions > > to slip right through. Unless some CFLAGS are set to warn or error on them. > > > > https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/C-Extensions.html#C-Exten > > sions > > > > Dennis > > > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > > visit: http://www.php.net/unsub.php > > We are actually much closer to C99 than we are to C90. As proof of this try > compiling with GCC with `-std=c90 -pedantic-errors` and then try it with `- > std=c99 -pedantic-errors`. You have to make significantly fewer changes to get > the C99 version working (or at least this was the case when it was last > brought > up). Also, ISO C90 and ANSI (C89) are essentially the same thing in case > anyone is > not aware. > Even without that - we already use inline, datatypes and macros, other things that don't belong to C89. We also use _declspec(thread) aka __thread which is not standardized at all. The GNU extensions, or VS features, or any other compiler specifics, are same as before. What matters, is the core C99 standard, or at least the part implemented in any known compiler, as some #ifdefs for platform/compiler specific non C99 features will always exist. While at the start, it'll probably be only to make the current source to rock with C99 compilers and to be able to use some syntax/semantic sugar, later contributions indeed using any possible other C99 features will appear. That's the point I actually wanted to make - moving to C99, we enable a set of new features not available with the ANSI C, that we need to internalize and accept.
Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
