Front page | perl.perl5.porters |
Postings from May 2003
[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.