On 2013-03-07 20:28, Dimitry Andric wrote: > On 2013-03-07 18:24, Tijl Coosemans wrote: >> Whatever the command line arguments, running c89 almost always results in >> the following output. Anyone else seeing this? >> >> c89: illegal option -- 1 >> usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] >> ... >> [-o outfile] [-U name] ... operand ... >> >> where operand is one or more of file.c, file.o, file.a >> or -llibrary > > Does anybody ever actually use this tool, really? :-) > > In any case, what happens is that /usr/bin/c89 builds up an argv[] > array, prepending the flags "-std=iso9899:199409" and "-pedantic" to the > other arguments, but it sets argv[0] to "/usr/bin/c89" too. > > If /usr/bin/cc is gcc, this causes no problems, since gcc always runs > /usr/libexec/cc1 for its first stage compilation process. It basically > ignores the value of argv[0]. > > When /usr/bin/cc is clang, however, it uses argv[0] to run its first > stage compilation, with -cc1 as the first argument. So this will run > /usr/bin/c89 yet again, and that complains about the unrecognized '1' > option. > > It can be solved very easily, by letting c89.c set argv[0] to > /usr/bin/cc instead, similar to c99.c, as with this diff: > > Index: usr.bin/c89/c89.c > =================================================================== > --- usr.bin/c89/c89.c (revision 247448) > +++ usr.bin/c89/c89.c (working copy) > @@ -72,7 +72,7 @@ main(int argc, char **argv) > Argv.a = malloc((argc + 1 + N_ARGS_PREPENDED) * sizeof *Argv.a); > if (Argv.a == NULL) > err(1, "malloc"); > - Argv.a[Argc++] = argv[0]; > + Argv.a[Argc++] = CC; > for (j = 0; j < N_ARGS_PREPENDED; ++j) > Argv.a[Argc++] = args_prepended[j]; > while ((i = getopt(argc, argv, "cD:EgI:l:L:o:OsU:")) != -1) { > > >> Also, I seem to remember a discussion about making -std=gnu89 the default >> for clang when run as "cc", but nothing seems to have changed. Could this >> be picked up again, because there are in fact subtle semantic differences >> between gnu89 inline and c99 inline that old code may rely on. > > Why on earth would you want gnu89 still as the default in 2013? I would > rather have it default to C11, but the support for this isn't complete > yet... :-)
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.
signature.asc
Description: OpenPGP digital signature