[Bug preprocessor/16358] New: -Wno-system-headers hides warning caused by user header vs system header conflict

[Bug preprocessor/16358] New: -Wno-system-headers hides warning caused by user header vs system header conflict

[avi at exanet dot com]

Consider the code

  #define BLOCK_SIZE 4096
  #include <linux/fs.h>

The header re#defines BLOCK_SIZE. Now, -Wno-system-headers suppresses the
warning as it comes in a system header, and the result is that BLOCK_SIZE is
silently redefined to 1024.

This can probably be fixed by considering all sources of a multi-source warning
(like symbol redefinition) when checking whether to suppress the warning or not.

-- 
           Summary: -Wno-system-headers hides warning caused by user header
                    vs system header conflict
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: avi at exanet dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-redhat-linux
  GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[avi at exanet dot com]

------- Additional Comments From avi at exanet dot com  2004-07-04 08:08 -------
Created an attachment (id=6684)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=6684&action=view)
Testcase. Linux specific, but can be readily adapted to other systems.


-- 


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[avi at exanet dot com]

------- Additional Comments From avi at exanet dot com  2004-07-04 08:11 -------
An obvious workaround is to perform all system #includes before everything else.
But there are valid reasons to #include system headers later, and a problem may
still remain with #include guard symbols.

-- 


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-04 14:44 -------
And why do you think we should warn here because the redefine is in a system header file?  Also you 
should not be including the kernel headers in user land programs.

-- 


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[avi at exanet dot com]

------- Additional Comments From avi at exanet dot com  2004-07-04 14:57 -------
(In reply to comment #3)
> And why do you think we should warn here because the redefine is in a system
header file? 

The user gets an unexpected value for their define. I wanted BLOCK_SIZE to be
4096, and I wanted the value of BLKBSZGET. I didn't know that linux/fs.h defines
BLOCK_SIZE, and I assumed that if it did I'd get a warning.

As it was, my code was silently broken.


 Also you 
> should not be including the kernel headers in user land programs.

I needed an ioctl definition. But this is true for non-kernel headers as well:

  // define some options:

  #define O_SCP     1  // use /usr/bin/scp
  #define O_WGET    2  // use /usr/bin/wget
  #define O_RSYNC   3  // use /usr/bin/rsync

  // ...

  #include <fcntl.h>  // oops: silently redefines O_RSYNC

The user may not be aware that O_RSYNC exists.



-- 


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-04 15:04 -------
Since O_RSYNC is reserved by the UNIX standard that part is invalid.  Yes there is such a thing, see 
<http://www.opengroup.org/onlinepubs/007908799/xsh/open.html> for the standard definition.

If you do not know what the marcos you are being in by using the headers why are you bring in the 
headers.  Also it is always custumary to include system headers first and then do the defines/includes 
of the user headers and you will never run into this.

Again this is invalid as the redefinition is the system header and the system header depends on the 
macros being defined right.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[avi at exanet dot com]

------- Additional Comments From avi at exanet dot com  2004-07-04 16:07 -------
(In reply to comment #5)
> Since O_RSYNC is reserved by the UNIX standard that part is invalid.  Yes
there is such a thing, see 
> <http://www.opengroup.org/onlinepubs/007908799/xsh/open.html> for the standard
definition.

If it is reserved, my code shouldn't compile if I define it.

if I do

  #include <fcntl.h>
  #define O_RSYNC blah

I get a warning. If I switch the order of the lines, I don't. The code compiles
after silently overriding my #define.



> 
> If you do not know what the marcos you are being in by using the headers why
are you bring in the 
> headers. 

Say I wanted O_SYNC, and knew about that. Or I included some other file that
included it. In a complex program a very large amount of headers can be expected
to be used. It's unreasonable to expect the user to know about all defines in a
header (did you know about O_RSYNC? I didn't).

 Also it is always custumary to include system headers first and then do the
defines/includes 
> of the user headers and you will never run into this.

This is a valid workaround.

> 
> Again this is invalid as the redefinition is the system header and the system
header depends on the 
> macros being defined right.

The code _is_ invalid, no doubt. I just want a warning, that's all. Shouldn't
gcc reject invalid code?

-- 


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-07-05 16:15 -------
I agree with Avi. The system header doesn't do a #undef + #define, but just a 
#define and it silently overwrites the previous macro. Even if this is 
undefined behaviour, we can do better than we do now and emit at least a 
warning.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug preprocessor/16358] -Wno-system-headers hides warning caused by user header vs system header conflict

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-04 00:13:51
               date|                            |


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