Problem with glibc headers and -D_FORTIFY_SOURCE=2

[ismail]

Bugzilla Link	11681
Resolution	INVALID
Resolved on	Jan 06, 2012 14:55
Version	trunk
OS	Linux
Attachments	Preprocessed source code
CC	@asl,@chandlerc,@efriedma-quic

Extended Description

idoenmez@havana:~> cat t.c
#include <stdio.h>

extern int asprintf (char **, const char *, ...) attribute((format(printf,2,3)));

idoenmez@havana:~> clang -O2 -D_FORTIFY_SOURCE=2 -fstack-protector -D_GNU_SOURCE -c -save-temps t.c
In file included from t.c:1:
t.c:3:37: error: expected parameter declarator
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^
t.c:3:37: error: expected ')'
t.c:3:27: note: to match this '('
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^
t.c:3:12: error: conflicting types for '__asprintf_chk'
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^
/usr/include/bits/stdio2.h:133:12: note: previous declaration is here
extern int __asprintf_chk (char **__restrict __ptr, int __flag,
^
In file included from t.c:1:
t.c:3:78: error: 'format' attribute parameter 2 is out of bounds
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^ ~
4 errors generated.

Preprocessed source code is attached.

[efriedma-quic]

It looks like your headers define asprintf as a macro. Why do you think there is a clang bug?

[ismail]

It looks like your headers define asprintf as a macro. Why do you think there
is a clang bug?

Because gcc happens to accept same code :-) And this is used in many applications thats why I reported it.

[ismail]

icc 12.1.0 seems to handle the same code fine too.

[efriedma-quic]

Okay... then something is going wrong in the preprocessor. "int __asprintf_chk (char **, 2 - 1, const char *, ...)" is clearly not a valid .declaration in C.

[ismail]

Preprocessed source code from gcc

[ismail]

gcc's preprocessed source code shows similar constructs. and icc again is able to handle this preprocessed code, but both gcc & icc doesn't handle clang's preprocessed code:

[~]> icc -c t.i
t.c(3): error: expected a type specifier
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^

t.c(3): error: format argument does not have string type
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^

t.c(3): error: first substitution argument is not the first variable argument
extern int __asprintf_chk (char **, 2 - 1, const char *, ...) attribute((format(printf,2,3)));
^

compilation aborted for t.i (code 2)

[ismail]

clang can compile icc's precompiled source code so it looks like clang is confused by glibc headers and producing wrong code.

[ismail]

s/precompiled/preprocessed

sorry!

[llvmbot]

glibc likes to play with GNUC. In this particular case, if __va_arg_pack is defined, it uses inline functions. If it is not, it uses macros (see stdio2.h).

And __va_arg_pack is declared only if the compiler claims to be gcc 4.3 or newer.

I have once coded a patch that makes clang impersonate the gcc whose headers it is using. Chandler convinced me to try to patch glibc and to my surprised that worked (d2daaa1eb6deaa17f6c9bc110cf7d927d8dcd767).

I would suggest trying to patch glibc. If that fails I can send the patch that changes the gcc we impersonate.

[efriedma-quic]

Ah, OK, that makes sense. __va_arg_pack is bug 11681.

I'm tempted to just mark this invalid. As far as I can tell, your testcase in invalid, and just gets lucky on lucky on gcc >= 4.3.

[ismail]

glibc likes to play with GNUC. In this particular case, if __va_arg_pack is
defined, it uses inline functions. If it is not, it uses macros (see stdio2.h).

And __va_arg_pack is declared only if the compiler claims to be gcc 4.3 or
newer.

I have once coded a patch that makes clang impersonate the gcc whose headers it
is using. Chandler convinced me to try to patch glibc and to my surprised that
worked (d2daaa1eb6deaa17f6c9bc110cf7d927d8dcd767).

I would suggest trying to patch glibc. If that fails I can send the patch that
changes the gcc we impersonate.

You mean d2daaa1eb6deaa17f6c9bc110cf7d927d8dcd767 would fix this?

[efriedma-quic]

Ah, OK, that makes sense. __va_arg_pack is bug 11681.

Err, I meant to say bug 7219.

[llvmbot]

Ah, OK, that makes sense. __va_arg_pack is bug 11681.

I'm tempted to just mark this invalid. As far as I can tell, your testcase in
invalid, and just gets lucky on lucky on gcc >= 4.3.

Makes sense. Looks like glibc has broken code for "gcc" <= 4.2.

Once 7219 is fixed we might open o new bug for "support impersonating a newer gcc".

[llvmbot]

You mean d2daaa1eb6deaa17f6c9bc110cf7d927d8dcd767 would fix this?

No, that was the glibc patch I wrote for the last case I found where it had broken code for "gcc" <= 4.2.