patch: perl 5.8.0 compile error on ia64/HP-UX (broken attribute test)

p5pRT commented 21 years ago

Migrated from rt.perl.org#22189 (status was 'resolved')

Searchable as RT22189$

p5pRT commented 21 years ago

From pere@hungry.com

I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:

__attribute__ ((__format__(__printf__\, 1\, 2)));

Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h. I also printed the result of the test to stdout\, making it easy see that this test now fails as it should on HP/UX.

With the following patch\, I got past the previous problem area. Please include this patch in the next version of perl.

Inline Patch

```diff diff -ur src-5.8.0/Configure src-5.8.0-local/Configure --- src-5.8.0/Configure 2002-07-19 00:55:15.000000000 +0200 +++ src-5.8.0-local/Configure 2003-05-13 20:23:30.000000000 +0200 @@ -9382,18 +9382,18 @@ echo "Checking whether your compiler can handle __attribute__ ..." >&4 $cat >attrib.c <<'EOCP' #include -void croak (char* pat,...) __attribute__((format(printf,1,2),noreturn)); +void croak (char* pat,...) __attribute__((__format__(__printf__,1,2),noreturn)); EOCP if $cc $ccflags -c attrib.c >attrib.out 2>&1 ; then if $contains 'warning' attrib.out >/dev/null 2>&1; then - echo "Your C compiler doesn't fully support __attribute__." + echo "Your C compiler doesn't fully support __attribute__." >&4 val="$undef" else - echo "Your C compiler supports __attribute__." + echo "Your C compiler supports __attribute__." >&4 val="$define" fi else - echo "Your C compiler doesn't seem to understand __attribute__ at all." + echo "Your C compiler doesn't seem to understand __attribute__ at all." >&4 val="$undef" fi set d_attribut ```

p5pRT commented 21 years ago

From @doughera88

On Tue\, 13 May 2003\, Petter Reinholdtsen wrote:

I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:
\_\_attribute\_\_ $\(\_\_format\_\_\(\_\_printf\_\_\, 1\, 2$\)\);
Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h.

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.

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

Actually\, it does print the result. You just told Configure to suppress that information by supplying the -s switch to Configure. Configure similarly suppresses other outputs from the "Checking ..." sorts of tests. If you don't want Configure to suppress information\, don't supply the -s switch.

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.

-- Andy Dougherty doughera@lafayette.edu

p5pRT commented 21 years ago

From Robin.Barker@npl.co.uk

Hi

I changed 'printf' to '__printf__' in the format enabled by CHECKFORMAT because the 'printf' was caught up in stdio/sfio MACRO merry-go-round.

I could have changed format but it wasn't a problem\, and I didn't know it was an option.

I think the remaining 'format's and 'printf's should be changed to '__format__' and '__printf__'\, including in Configure.

Robin

-----Original Message----- From: Andy Dougherty [mailto:doughera@lafayette.edu] Sent: 14 May 2003 15:26 To: perl5-porters@perl.org Subject: Re: [perl #22189] patch: perl 5.8.0 compile error on ia64/HP-UX (broken attribute test)

On Tue\, 13 May 2003\, Petter Reinholdtsen wrote:

I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:
\_\_attribute\_\_ $\(\_\_format\_\_\(\_\_printf\_\_\, 1\, 2$\)\);
Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h.

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.

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

Actually\, it does print the result. You just told Configure to suppress that information by supplying the -s switch to Configure. Configure similarly suppresses other outputs from the "Checking ..." sorts of tests. If you don't want Configure to suppress information\, don't supply the -s switch.

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.

-- Andy Dougherty doughera@lafayette.edu

This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington\, Middlesex\, United Kingdom TW11 0LW.

p5pRT commented 21 years ago

From pere@hungry.com

[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.

p5pRT commented 21 years ago

From Robin.Barker@npl.co.uk

The format attributes are not normally visible to the compiler. Unless you are using -DCHECK_FORMAT\, the __printf__ are not seen. The attribute setting in perlio.h were not protected by C\<ifdef CHECK_FORMAT> -- this is a bug and was fixed by my patch 18556.

Robin

-----Original Message----- From: Petter Reinholdtsen [mailto:perlbug-followup@perl.org] Sent: 13 May 2003 19:42 To: perl5-porters@perl.org Subject: [perl #22189] patch: perl 5.8.0 compile error on ia64/HP-UX (broken attribute test)

# New Ticket Created by Petter Reinholdtsen # Please include the string: [perl #22189] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22189 >

I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:

__attribute__ ((__format__(__printf__\, 1\, 2)));

Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h. I also printed the result of the test to stdout\, making it easy see that this test now fails as it should on HP/UX.

With the following patch\, I got past the previous problem area. Please include this patch in the next version of perl.

Inline Patch

```diff diff -ur src-5.8.0/Configure src-5.8.0-local/Configure --- src-5.8.0/Configure 2002-07-19 00:55:15.000000000 +0200 +++ src-5.8.0-local/Configure 2003-05-13 20:23:30.000000000 +0200 @@ -9382,18 +9382,18 @@ echo "Checking whether your compiler can handle __attribute__ ..." >&4 $cat >attrib.c <<'EOCP' #include -void croak (char* pat,...) ```

attribute((format(printf,1,2),noreturn)); +void croak (char* pat\,...) __attribute__((__format__(__printf__\,1\,2)\,noreturn)); EOCP if $cc $ccflags -c attrib.c >attrib.out 2>&1 ; then if $contains 'warning' attrib.out >/dev/null 2>&1; then - echo "Your C compiler doesn't fully support __attribute__." + echo "Your C compiler doesn't fully support __attribute__." >&4 val="$undef" else - echo "Your C compiler supports __attribute__." + echo "Your C compiler supports __attribute__." >&4 val="$define" fi else - echo "Your C compiler doesn't seem to understand __attribute__ at all." + echo "Your C compiler doesn't seem to understand __attribute__ at all." >&4 val="$undef" fi set d_attribut

This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington\, Middlesex\, United Kingdom TW11 0LW.

p5pRT commented 21 years ago

From @jhi

I applied other parts of the patch except for the MIME::Base64 parts that I forwarded to Gisle\, he will decide what to do with those. Therefore I'm marking this problem ticket as resolved.

p5pRT commented 21 years ago

@jhi - Status changed from 'new' to 'resolved'

p5pRT commented 21 years ago

From nick@ing-simmons.net

Robin Barker \Robin\.Barker@npl\.co\.uk writes:

Hi

I changed 'printf' to '__printf__' in the format enabled by CHECKFORMAT because the 'printf' was caught up in stdio/sfio MACRO merry-go-round.

I could have changed format but it wasn't a problem\, and I didn't know it was an option.

I think the remaining 'format's and 'printf's should be changed to '__format__' and '__printf__'\, including in Configure.

Robin

That depends if HP/UX really undestands the forms without the __ then why should we limit ourselves to the gcc-ish __ forms?

-----Original Message----- From: Andy Dougherty [mailto:doughera@lafayette.edu] Sent: 14 May 2003 15:26 To: perl5-porters@perl.org Subject: Re: [perl #22189] patch: perl 5.8.0 compile error on ia64/HP-UX (broken attribute test)

On Tue\, 13 May 2003\, Petter Reinholdtsen wrote:
I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:
\_\_attribute\_\_ $\(\_\_format\_\_\(\_\_printf\_\_\, 1\, 2$\)\);
Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h.
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.

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

Actually\, it does print the result. You just told Configure to suppress that information by supplying the -s switch to Configure. Configure similarly suppresses other outputs from the "Checking ..." sorts of tests. If you don't want Configure to suppress information\, don't supply the -s switch.

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.

-- Andy Dougherty doughera@lafayette.edu

------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington\, Middlesex\, United Kingdom TW11 0LW. ------------------------------------------------------------------- -- Nick Ing-Simmons http://www.ni-s.u-net.com/

p5pRT commented 21 years ago

From @tux

On Sat 17 May 2003 19:39\, Nick Ing-Simmons \nick@ing\-simmons\.net wrote:

Robin Barker \Robin\.Barker@npl\.co\.uk writes:

Hi

I changed 'printf' to '__printf__' in the format enabled by CHECKFORMAT because the 'printf' was caught up in stdio/sfio MACRO merry-go-round.

I could have changed format but it wasn't a problem\, and I didn't know it was an option.

I think the remaining 'format's and 'printf's should be changed to '__format__' and '__printf__'\, including in Configure.

Robin

That depends if HP/UX really undestands the forms without the __ then why should we limit ourselves to the gcc-ish __ forms?

What should I test? (HP-UX 10.20 and 11.00 available)

-- H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1\, 5.8.0 & 633 on HP-UX 10.20 & 11.00\, AIX 4.2\, AIX 4.3\, WinNT 4\, Win2K pro & WinCE 2.11. Smoking perl CORE: smokers@perl.org http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org send smoke reports to: smokers-reports@perl.org\, QA: http://qa.perl.org

p5pRT commented 21 years ago

From Robin.Barker@npl.co.uk

Nick

Something needs to change -- at the moment nostdio.h defines 'printf' as 'CANNOT _printf_'\, so 'format(printf\,1\,2)' becomes 'format(CANNOT _printf_\,1\,2)' which does not parse. (You only get this with -DCHECK_FORMAT.)

Using '__printf__' seemed the neated way to fix this.

Robin

-----Original Message----- From: Nick Ing-Simmons [mailto:nick@ing-simmons.net] Sent: 17 May 2003 18:39 To: Robin.Barker@npl.co.uk Cc: 'Andy Dougherty'; perl5-porters@perl.org Subject: RE: [perl #22189] patch: perl 5.8.0 compile error on ia64/HP-UX ( broken attribute test)

Robin Barker \Robin\.Barker@npl\.co\.uk writes:

Hi

I changed 'printf' to '__printf__' in the format enabled by CHECKFORMAT because the 'printf' was caught up in stdio/sfio MACRO merry-go-round.

I could have changed format but it wasn't a problem\, and I didn't know it was an option.

I think the remaining 'format's and 'printf's should be changed to '__format__' and '__printf__'\, including in Configure.

Robin

That depends if HP/UX really undestands the forms without the __ then why should we limit ourselves to the gcc-ish __ forms?

-----Original Message----- From: Andy Dougherty [mailto:doughera@lafayette.edu] Sent: 14 May 2003 15:26 To: perl5-porters@perl.org Subject: Re: [perl #22189] patch: perl 5.8.0 compile error on ia64/HP-UX (broken attribute test)

On Tue\, 13 May 2003\, Petter Reinholdtsen wrote:
I ran into a compile error when trying to compile perl 5.8.0 on ia64 HP/UX 11.22. I got this error message when trying to compile miniperlmain.c:

Error 172: "perlio.h"\, line 209 # Undeclared variable '__printf__'.

The problem was the following code:
\_\_attribute\_\_ $\(\_\_format\_\_\(\_\_printf\_\_\, 1\, 2$\)\);
Tracking the problem further\, I discovered the test for __attribute__ in Configure\, where it is testing if the following construct is compilable:

#include \<stdio.h> void croak (char* pat\,...) __attribute__((format(printf\,1\,2)\,noreturn));

I belive the test in Configure should test for the same feature that is used in the perl code\, and rewrote 'format' to '__format__' and 'printf' to '__printf__' to match perlio.h.
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.

I also discovered that the result from this test isn't printed to stdout\, making it hard to find out what the result from this test was.

Actually\, it does print the result. You just told Configure to suppress that information by supplying the -s switch to Configure. Configure similarly suppresses other outputs from the "Checking ..." sorts of tests. If you don't want Configure to suppress information\, don't supply the -s switch.

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.

-- Andy Dougherty doughera@lafayette.edu

------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington\, Middlesex\, United Kingdom TW11 0LW. ------------------------------------------------------------------- -- Nick Ing-Simmons http://www.ni-s.u-net.com/

This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee\, you must not use\, retain or disclose such information.

NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses.

NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington\, Middlesex\, United Kingdom TW11 0LW.

p5pRT commented 21 years ago

From nick.ing-simmons@elixent.com

Robin Barker \Robin\.Barker@npl\.co\.uk writes:

Nick

Something needs to change

Apparently!

-- at the moment nostdio.h defines 'printf' as 'CANNOT _printf_'\, so 'format(printf\,1\,2)' becomes 'format(CANNOT _printf_\,1\,2)' which does not parse. (You only get this with -DCHECK_FORMAT.)

For some meaning of "at the moment". I am reasonably sure we fixed the #define of printf in bleadperl (post 5.8.0) It does not only mess up attributes but also preculdes using printf() in XS code in general - in the brave new PerlIO world that is allowed.

In older perls the ordering of the #include-s via perl.h is supposed to be cleverly (diabolically?) contrived so that the attributes worked. I know that when that printf mess went in the equivalent of -DCHECK_FORMAT was the default (at least for gcc I habitually used). I guess that now CHECK_FORMAT is optional (because of all the %_ stuff makes it noisy) - patches may have broken the clever ordering and we only just noticed.

Using '__printf__' seemed the neated way to fix this.

But suppose (as seems to be the case) HP/UX compiler supports format(printf\,...) but does NOT support format(__printf__\,...)? Do we want to stop HP/UXers do -DCHECK_FORMAT?

The easiest way is #undef printf

the best way is loose the #define.

-- Nick Ing-Simmons http://www.ni-s.u-net.com/

p5pRT commented 21 years ago

From @doughera88

On Sat\, 17 May 2003\, Nick Ing-Simmons wrote:

I think the remaining 'format's and 'printf's should be changed to '__format__' and '__printf__'\, including in Configure.

I agree with that. And it's certainly clear that Configure ought to be testing whatever perl ends up actually using.

That depends if HP/UX really undestands the forms without the __ then why should we limit ourselves to the gcc-ish __ forms?

It wasn't clear to me that HP/UX was actually doing anything useful with the "attribute". If I recall correctly\, the original poster was using a compiler called "cc-wrapper". I have no idea exactly what that "wrapper" is actually doing.

More to the point\, I think we have plenty of gcc users on p5p anyway who can catch printf formatting errors; it's probably not worth too much effort to expand the checking further.

-- Andy Dougherty doughera@lafayette.edu

p5pRT commented 21 years ago

From pere@hungry.com

[Andy Dougherty]

If I recall correctly\, the original poster was using a compiler called "cc-wrapper". I have no idea exactly what that "wrapper" is actually doing.

It just make sure we can use the same compiler setting on all our 9 unix architectures. On HP/UX\, it turns into this:

PATH=/opt/ansic/bin:$PATH cc +DD64 -Ae -O -I/local/include -L/local/lib

p5pRT commented 20 years ago

From @jhi

I believe this problem got fixed\, and am therefore marking the problem ticket as resolved. Perl 5.8.1 Release Candidates should start coming out soon-ish\, stay tuned.

p5pRT commented 20 years ago

@jhi - Status changed from 'open' to 'resolved'

Perl / perl5