From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 7 19:28:15 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F46E97D for ; Thu, 7 Mar 2013 19:28:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id DC210E62 for ; Thu, 7 Mar 2013 19:28:14 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E7825C43; Thu, 7 Mar 2013 20:28:11 +0100 (CET) Message-ID: <5138EA4C.1060001@FreeBSD.org> Date: Thu, 07 Mar 2013 20:28:12 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Tijl Coosemans , toolchain@freebsd.org Subject: Re: c89 broken on head? References: <5138CD6B.2050309@coosemans.org> In-Reply-To: <5138CD6B.2050309@coosemans.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 19:28:15 -0000 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... :-)