Bug 469866

Summary: Can't #include <unistd.h> in a function with -O -D_FORTIFY_SOURCE
Product: [Fedora] Fedora Reporter: Jerry James <loganjerry>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: jakub
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-04 15:34:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.