order of -D and -U is significant

order of -D and -U is significant

[Unruh, Erwin]

In current gcc the order of options -D and -U is significant. The Single Unix(r)
Specification explicitly specifies that the order should not matter for the c89 
command. It reads (cited from version 2, which is ten years old):

-D name[=value]
Define name as if by a C-language #define directive. If no =value is given,
a value of 1 will be used. The -D option has lower precedence than the -U
option. That is, if name is used in both a -U and a -D option, name will be
undefined regardless of the order of the options. Additional
implementation-dependent names may be provided by the compiler. Implementations
support at least 2048 bytes of -D definitions and 256 names. 

I did not find a justification for the current gcc behavior. Searching revealed
a patch which implemented the behavior:
	http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00621.html
and two messages earlier that year which might be relevant:
	http://gcc.gnu.org/ml/gcc/2000-09/msg00673.html
	http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01271.html
The original bug report was:
	http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00605.html
Neither message mentions a possible dependency to the unix specification.
Three years later the code went from the preprocessor to the frontend
	http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01432.html

I now have two questions:
1) Does anybody recall a discussion of this topic?
2) Is this a bug?

	Erwin

Re: order of -D and -U is significant

[Paolo Bonzini]

On 08/03/2009 03:52 PM, Unruh, Erwin wrote:
> 2) Is this a bug?

I think it's a bug in the specification.

User-specified CFLAGS are always passed last in the Makefiles (at least 
for Automake, but it is a good practice in general) so that the user can 
override options like -D, -U, -O, -g, -f, -m.

The specified behavior would make this impossible.

Paolo

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-04 08:23:52 +0200, Paolo Bonzini wrote:
> User-specified CFLAGS are always passed last in the Makefiles (at
> least for Automake, but it is a good practice in general) so that
> the user can override options like -D, -U, -O, -g, -f, -m.
> 
> The specified behavior would make this impossible.

Yes, but this is already non-portable anyway and there are other
things that are impossible (such as overriding -I). How about a
new way to override options or define a precedence and which could
work with other options?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-03 15:52:37 +0200, Unruh, Erwin wrote:
> In current gcc the order of options -D and -U is significant. The
> Single Unix(r) Specification explicitly specifies that the order
> should not matter for the c89 command. It reads (cited from
> version 2, which is ten years old):
[...]

FYI, I reported a bug there:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960

(but I mentioned c99 instead of c89, as this is what's in the
current discussion in the austin-group list).

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: order of -D and -U is significant

[Tom Tromey]

>>>>> "Erwin" == Unruh, Erwin <erwin.unruh@ts.fujitsu.com> writes:

Erwin> In current gcc the order of options -D and -U is significant. The
Erwin> Single Unix(r) Specification explicitly specifies that the order
Erwin> should not matter for the c89 command. It reads (cited from
Erwin> version 2, which is ten years old):

Erwin> I did not find a justification for the current gcc
Erwin> behavior.

GCC's behavior is more useful.  And, given its age, I think it would be
a mistake to change it.

I think if you want the c89 behavior, a wrapper program of some kind
would be the way to go.

Tom

Re: order of -D and -U is significant

[Joe Buck]

On Tue, Aug 04, 2009 at 08:03:56AM -0700, Tom Tromey wrote:
> >>>>> "Erwin" == Unruh, Erwin <erwin.unruh@ts.fujitsu.com> writes:
> 
> Erwin> In current gcc the order of options -D and -U is significant. The
> Erwin> Single Unix(r) Specification explicitly specifies that the order
> Erwin> should not matter for the c89 command. It reads (cited from
> Erwin> version 2, which is ten years old):
> 
> Erwin> I did not find a justification for the current gcc
> Erwin> behavior.
> 
> GCC's behavior is more useful.  And, given its age, I think it would be
> a mistake to change it.
> 
> I think if you want the c89 behavior, a wrapper program of some kind
> would be the way to go.

Another alternative would be an extra flag that would turn on conformance
to the spec.  But gcc can't change its default behavior; this would cause
massive breakage.

Re: order of -D and -U is significant

[Ross Smith]

On 2009-08-05, at 04:03, Joe Buck wrote:
>
> Another alternative would be an extra flag that would turn on  
> conformance
> to the spec.

Traditionally spelled -posixly-correct in other GNU software. This would
presumably also affect other options, such as making the default - 
std=c99
instead of gnu89.

-- Ross Smith

Re: order of -D and -U is significant

[Joe Buck]

On Tue, Aug 04, 2009 at 11:42:51AM -0700, Ross Smith wrote:
> 
> On 2009-08-05, at 04:03, Joe Buck wrote:
> >
> > Another alternative would be an extra flag that would turn on
> > conformance
> > to the spec.
> 
> Traditionally spelled -posixly-correct in other GNU software. This would
> presumably also affect other options, such as making the default -
> std=c99
> instead of gnu89.

But AFAIK neither Posix nor the C89 standard nor the C99 standard
say anything about -D and -U flags.  It's the Single UNIX specification
that is the issue, and it refers to a command that is spelled "c89",
or (in later versions) "c99", not "gcc".

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> But AFAIK neither Posix nor the C89 standard nor the C99 standard
> say anything about -D and -U flags.  It's the Single UNIX specification
> that is the issue, and it refers to a command that is spelled "c89",
> or (in later versions) "c99", not "gcc".

c99 with the mentioned -D and -U flags is specified by:

The Open Group Base Specifications Issue 7
IEEE Std 1003.1-2008

That's POSIX.1-2008.

See http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: order of -D and -U is significant

[Dave Korn]

Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
>> But AFAIK neither Posix nor the C89 standard nor the C99 standard
>> say anything about -D and -U flags.  It's the Single UNIX specification
>> that is the issue, and it refers to a command that is spelled "c89",
>> or (in later versions) "c99", not "gcc".
> 
> c99 with the mentioned -D and -U flags is specified by:

  GCC does not install an executable called "c99".  Or one called "c89".  So
what any standard requires of them is irrelevant to us, except that we would
want to make it possible to support that mode of operation.  And we do; with our
predictable behaviour, all "c89" has to do is sort the command-line options so
all the -Ds come first and all the -Us come last, and then invoke "gcc".  I'm
sure nobody will raise any objection to adding a command-line flag if you want
to integrate this behaviour into the driver.  Perhaps we could even do the old
behave-differently-according-to-argv[0] trick, although I'm not sure if that
isn't slightly discouraged these days.

    cheers,
      DaveK

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
>   GCC does not install an executable called "c99". Or one called
> "c89". So what any standard requires of them is irrelevant to us,
> except that we would want to make it possible to support that mode
> of operation. And we do; with our predictable behaviour, all "c89"
> has to do is sort the command-line options so all the -Ds come first
> and all the -Us come last, and then invoke "gcc".

Recognizing options may depend on the GCC version. Or do GCC developers
guaranty that no options that can take an argument will be added in the
future?

> I'm sure nobody will raise any objection to adding a command-line
> flag if you want to integrate this behaviour into the driver.

This would be better.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: order of -D and -U is significant

[Dave Korn]

Vincent Lefevre wrote:
> On 2009-08-05 10:07:49 +0100, Dave Korn wrote:
>>   GCC does not install an executable called "c99". Or one called
>> "c89". So what any standard requires of them is irrelevant to us,
>> except that we would want to make it possible to support that mode
>> of operation. And we do; with our predictable behaviour, all "c89"
>> has to do is sort the command-line options so all the -Ds come first
>> and all the -Us come last, and then invoke "gcc".
> 
> Recognizing options may depend on the GCC version. Or do GCC developers
> guaranty that no options that can take an argument will be added in the
> future?

  I'm trying hard to think of a case where an option argument might begin with
-U or -D and not succeeding, but I guess it's possible in theory that some
future option might want to take arguments like that (otherwise, there's no
parsing ambiguity).  Users of a hypothetical c89 wrapper script would want to
use the joined form of the switches for those arguments!

  Also, just as an illustration, the libtool project doesn't seem to find
keeping up with the rate of change of GCC options a serious burden, because
almost all the churn is in things like -f and -m that stick to the current
formats, and there are only very rarely entirely new classes of option format added.

>> I'm sure nobody will raise any objection to adding a command-line
>> flag if you want to integrate this behaviour into the driver.
> 
> This would be better.

  Notwithstanding all the above, I agree.  But I also think a wrapper script
/would/ be a practical solution for anyone who wanted it.

    cheers,
      DaveK

Re: order of -D and -U is significant

[Joseph S. Myers]

On Wed, 5 Aug 2009, Dave Korn wrote:

> to integrate this behaviour into the driver.  Perhaps we could even do the old
> behave-differently-according-to-argv[0] trick, although I'm not sure if that
> isn't slightly discouraged these days.

The proper thing is to build a separate driver binary (optionally, if 
configured to do so) and install it as "c99", rather than a wrapper script 
or depending on argv[0].

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: order of -D and -U is significant

[Joe Buck]

On Tue, Aug 04, 2009 at 05:58:05PM -0700, Vincent Lefevre wrote:
> On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> > But AFAIK neither Posix nor the C89 standard nor the C99 standard
> > say anything about -D and -U flags.  It's the Single UNIX specification
> > that is the issue, and it refers to a command that is spelled "c89",
> > or (in later versions) "c99", not "gcc".
> 
> c99 with the mentioned -D and -U flags is specified by:
> 
> The Open Group Base Specifications Issue 7
> IEEE Std 1003.1-2008
> 
> That's POSIX.1-2008.

OK, clearly I am out of date; the unix specification used to be distinct
from Posix.