Bug 40960 - POSIX requires that option -D have a lower precedence than -U
Summary: POSIX requires that option -D have a lower precedence than -U
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 82534
  Show dependency treegraph
 
Reported: 2009-08-04 11:52 UTC by Vincent Lefèvre
Modified: 2020-11-05 22:11 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-09-16 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Lefèvre 2009-08-04 11:52:05 UTC
[This concerns the POSIX c99 utility, but gcc should probably behave in the same way, as on some platforms, c99 is gcc.]

In http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html POSIX specifies:

  -D  name[=value]
    Define name as if by a C-language #define directive. If no = value
    is given, a value of 1 shall 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 shall be undefined regardless of the
    order of the options.

However, gcc doesn't take the precedence rule into account:

$ cat tst.c
int main(void)
{
#ifdef FOO
  return 1;
#else
  return 0;
#endif
}
$ c99 tst.c -UFOO -DFOO=1
$ ./a.out
zsh: exit 1     ./a.out

whereas FOO should be undefined and the return value should be 0, not 1.

I could reproduce this with various GCC versions, including:
gcc-snapshot (Debian 20090718-1) 4.5.0 20090718 (experimental) [trunk revision 149777]
Comment 1 Richard Biener 2009-08-04 12:19:36 UTC
Hm, I wonder how many makefiles we'd break with changing that.
Comment 2 Vincent Lefèvre 2009-08-04 13:29:59 UTC
There would the possibility to have a POSIX mode implied by c99, but I don't think having different behaviors would be a good idea. IMHO, Makefiles should be fixed to stick to POSIX.

Also, portable Makefiles, i.e. that work with other compilers, should not be affected.

Note that Sun cc 5.0 is correct. And gcc 2.95.3 was also correct! (That's old, but this is on an old Solaris machine where I still have an account.)
Comment 3 Jakub Jelinek 2009-08-04 14:01:57 UTC
And the GCC behavior makes much more sense than the POSIX required for c99.
Comment 4 jsm-csl@polyomino.org.uk 2009-08-04 14:54:13 UTC
Subject: Re:  POSIX requires that option -D have a lower precedence
 than -U

On Tue, 4 Aug 2009, vincent at vinc17 dot org wrote:

> There would the possibility to have a POSIX mode implied by c99, but I don't
> think having different behaviors would be a good idea. IMHO, Makefiles should

I think that installing a variant driver program as "c99", that implements 
the different semantics, is exactly the right thing to do here; the 
present semantics are more useful for "gcc".  We should have a configure 
option to install "cc", "c89" and "c99" drivers; they should have 
appropriate defaults regarding e.g. standards mode, and should also adjust 
the precedence of these options and make any other adjustments required by 
POSIX that aren't appropriate for "gcc".

Comment 5 Eric Gallager 2017-09-16 22:46:37 UTC
(In reply to joseph@codesourcery.com from comment #4)
> Subject: Re:  POSIX requires that option -D have a lower precedence
>  than -U
> 
> On Tue, 4 Aug 2009, vincent at vinc17 dot org wrote:
> 
> > There would the possibility to have a POSIX mode implied by c99, but I don't
> > think having different behaviors would be a good idea. IMHO, Makefiles should
> 
> I think that installing a variant driver program as "c99", that implements 
> the different semantics, is exactly the right thing to do here; the 
> present semantics are more useful for "gcc".  We should have a configure 
> option to install "cc", "c89" and "c99" drivers; they should have 
> appropriate defaults regarding e.g. standards mode, and should also adjust 
> the precedence of these options and make any other adjustments required by 
> POSIX that aren't appropriate for "gcc".

Confirmed, I think a configure option would be a good way to go about it.
Comment 6 Eric Gallager 2018-06-17 04:35:16 UTC
(In reply to Eric Gallager from comment #5)
> 
> Confirmed, I think a configure option would be a good way to go about it.

Other options as mentioned in bug 80535 comment 1 include respecting the POSIXLY_CORRECT environment variable, and/or adding a -posix-std= flag to mirror the existing -std= flag for the language standard