[Bug c/34710] FORTIFY_SOURCE matches to many patterns

[graeme at argyllcms dot com]

------- Comment #8 from graeme at argyllcms dot com  2008-02-09 01:37 -------
I've read this section of the standard, and don't see that
it is applicable. "Any function declared in a header may be additionally
implemented as a function-like macro defined in the header, so if a
library function is declared explicitly when its header is included, one
of the techniques shown below can be used to ensure the declaration is
not affected by such a macro."

This isn't applicable, since I'm not explicitly declaring the library
function fprintf. What I'm declaring is my function (that happens to
be called fprintf) as a member of a structure. They are two distinct
names and functions in different scopes.

The problem is that the function-like macro is being (wrongly) substituted
for something that isn't the library function declared in the header.

To claim that including a header makes all the identifiers in that
header reserved words for everything is simply unworkable I think.
Why is a #include file special code that doesn't obey the language scoping
rules ? Modern systems may have countless thousands of identifiers in their
headers, so how can anyone sitting down to do some programming avoid
using any of them for anything, including what are normally
private scope identifiers such as structure member names ?
This is exactly the opposite of modularization and information hiding!


-- 


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