Bug 469866 - Can't #include <unistd.h> in a function with -O -D_FORTIFY_SOURCE
Summary: Can't #include <unistd.h> in a function with -O -D_FORTIFY_SOURCE
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-04 15:19 UTC by Jerry James
Modified: 2008-11-04 15:38 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-11-04 15:34:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jerry James 2008-11-04 15:19:27 UTC
Description of problem:
The following program can be compiled successfully, unless both -O (or -O2 or -O3) and -D_FORTIFY_SOURCE (or -D_FORTIFY_SOURCE=2) are specified:

int main() {
#include <unistd.h>
  return 0;
}

With both optimization and source fortification turned on, gcc reports:

In file included from /usr/include/unistd.h:1100,
                 from test.c:2:
/usr/include/bits/unistd.h: In function 'main':
/usr/include/bits/unistd.h:36: error: nested function 'read' declared 'extern'
/usr/include/bits/unistd.h:35: error: static declaration of 'read' follows non-static declaration
/usr/include/unistd.h:327: error: previous declaration of 'read' was here

...

That is followed by identical complaints about readlink, getcwd, getwd, confstr, getgroups, etc.

Version-Release number of selected component (if applicable):
glibc-headers-2.8-8.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Copy the code above into test.c
2. gcc -D_FORTIFY_SOURCE -o test test.c: the compile succeeds
3. gcc -O -o test test.c: the compile succeeds
4. gcc -O -D_FORTIFY_SOURCE -o test test.c: the compile fails
  
Actual results:
Compilation fails.

Expected results:
Compilation succeeds.

Additional info:
This is the cause of a GCL build failure.  I can work around it for now, but it would be nice to get this fixed.

Comment 1 Jakub Jelinek 2008-11-04 15:34:39 UTC
Then GCL is buggy.  Standard headers are never meant to be included inside of a function.  E.g. ISO C99 says in 7.1.2/4:
... "If used, a header shall be included outside of any external declaration or definition, and it shall first be included before the first reference to any of the functions or objects it declares, or to any of the types or macros it defines."...

Comment 2 Jerry James 2008-11-04 15:38:18 UTC
In that case, I'll send my patch upstream and tell them that it is not a workaround, but a necessary fix.  Thanks, Jakub.


Note You need to log in before you can comment on or make changes to this bug.