Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Mar 2013 21:22:07 +0100
From:      Tijl Coosemans <tijl@coosemans.org>
To:        freebsd-toolchain@freebsd.org
Subject:   Re: c89 broken on head?
Message-ID:  <5138F6EF.6020203@coosemans.org>
In-Reply-To: <5138EA4C.1060001@FreeBSD.org>
References:  <5138CD6B.2050309@coosemans.org> <5138EA4C.1060001@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2TGKBMCTGFIAHOJLMTHRL
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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[=3Dvalue]] ... [-I directory] ... [-L dir=
ectory] ...
>>             [-o outfile] [-U name] ... operand ...
>>
>>         where operand is one or more of file.c, file.o, file.a
>>         or -llibrary
>=20
> Does anybody ever actually use this tool, really? :-)
>=20
> In any case, what happens is that /usr/bin/c89 builds up an argv[]
> array, prepending the flags "-std=3Diso9899:199409" and "-pedantic" to =
the
> other arguments, but it sets argv[0] to "/usr/bin/c89" too.
>=20
> 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].
>=20
> 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.
>=20
> 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:
>=20
> Index: usr.bin/c89/c89.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- 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 =3D malloc((argc + 1 + N_ARGS_PREPENDED) * sizeof *Argv.a);=

>      if (Argv.a =3D=3D NULL)
>          err(1, "malloc");
> -    Argv.a[Argc++] =3D argv[0];
> +    Argv.a[Argc++] =3D CC;
>      for (j =3D 0; j < N_ARGS_PREPENDED; ++j)
>          Argv.a[Argc++] =3D args_prepended[j];
>      while ((i =3D getopt(argc, argv, "cD:EgI:l:L:o:OsU:")) !=3D -1) {
>=20
>=20
>> Also, I seem to remember a discussion about making -std=3Dgnu89 the de=
fault
>> for clang when run as "cc", but nothing seems to have changed. Could t=
his
>> be picked up again, because there are in fact subtle semantic differen=
ces
>> between gnu89 inline and c99 inline that old code may rely on.
>=20
> Why on earth would you want gnu89 still as the default in 2013?  I woul=
d
> 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=3Dc11.


------enig2TGKBMCTGFIAHOJLMTHRL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iF4EAREIAAYFAlE49vcACgkQfoCS2CCgtiv6BwD/UeoFDPiET3Jbjj9oiF77cCFU
cMAZkEeAUT7/7AOuKqAA/2By4GxG/a9f83F0KC9bRjzvcQDA7qspKkQ0nNxu8uKP
=WOqz
-----END PGP SIGNATURE-----

------enig2TGKBMCTGFIAHOJLMTHRL--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5138F6EF.6020203>