[Andy Dougherty] > Unfortunately, both forms (format and __format__) are used in the perl > code. I don't know why. Nor do I understand why your compiler would > accept one but not the other. That's truly strange, and probably worth > investigating. Does your compiler actually support > __attribute__((format())) but not __attribute__((__format__())), or is the > test flawed in some other way such that __attribute__ isn't supported, but > we fail to adequately detect that. It is the other way around. It seem to support printf, but not __printf__. Or perhaps it uses the function pointer to printf()? Given the two files foo.c and foo2.c, I get this behavoiur: % cat foo.c #include <stdio.h> void croak (char* pat,...) __attribute__((format(printf,1,2),noreturn)); % cat foo2.c #include <stdio.h> void croak (char* pat,...) __attribute__((__format__(__printf__,1,2),noreturn)); % cc-wrapper -c foo.c % cc-wrapper -c foo2.c Error 172: "foo2.c", line 2 # Undeclared variable '__printf__'. void croak (char* pat,...) __attribute__((__format__(__printf__,1,2),noretu ^^^^^^^^^^ % Thus the Configure test fail. % uname -a; cc -V HP-UX unknown B.11.22 U ia64 unknown unknown HP-UX cc: HP aC++/ANSI C B3910B A.05.41 [Nov 1 2002] > In short, I have no objection to changing format to __format__ and > printf to __printf__, but it'd be nice to know just why it matters > so that we can make the test more robust so that this issue wouldn't > have come up in the first place. I do not know why it matters, but it does. I suspect it is safer to use __format__ and __printf__ in the source when this feature is used, to make sure the correct feature is used. > Actually, it does print the result. You just told Configure to > suppress that information by supplying the -s switch to Configure. Right. Good point. I didn't write the compile scripts I am using, and did not notice that switch. It is now removed, and that part of the patch is removed from my version. Thanks for the tip.