On 2013-03-08 04:07, Eitan Adler wrote: > On 7 March 2013 18:03, Tijl Coosemans <t...@coosemans.org> wrote: >> On 2013-03-07 22:36, Warner Losh wrote: >>> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: >>>> On 2013-03-07 21:22, Tijl Coosemans wrote: >>>> ... >>>>> Because it's the practical thing to do? Old code/makefiles >>>>> can't possibly be expected to know about compilers of the >>>>> future, while new code can be expected to add -std=c11. >>>> >>>> I am not sure I buy that argument; if it were so, we should >>>> default to K&R C instead, since "old code" (for some arbitrary >>>> definition of "old") could never have been expected to know >>>> about gcc defaulting to gnu89. >> >> My argument was to be practical, i.e. don't change what doesn't >> have to change. >> >>> -std=c11 is defintely too new, but maybe c89 is too old. >>> >>> I thought the c89 program actually was mandated by POSIX, no? >> >> Both were part of POSIX. c89 was a strict ISO c89 compiler, while >> cc was c89, but could additionally accept "an unspecified dialect >> of the C language". >> http://pubs.opengroup.org/onlinepubs/007908799/xcu/cc.html >> >> So, if practicality isn't a good enough argument, maybe POSIX >> compliance is? > > cc is marked as "LEGACY" which is described as optional ("need not > be provided"). > However, I would not be surprised if a non-zero number > of ports depend on cc existing. > > If we are to remove it or change it, I would like to see that > preceded by an exp-run.
The autoconf macro AC_PROG_CC_C89 fails when cc is clang. It says no flags are needed to enable C89 mode. It is used by devel/gdb for instance which now had to be patched because inline means something different in gnu89 versus C99. C99 is *not* backward compatible with gnu89: http://svnweb.freebsd.org/ports/head/devel/gdb/files/patch-include-cgen-basic-ops.h?revision=314093&view=markup
signature.asc
Description: OpenPGP digital signature
