develooper Front page | perl.perl5.porters | Postings from September 2003

Re: Interesting - [ Re: A user's experiences with GCC-3.4 snapshots]

Thread Previous | Thread Next
Mark Jason Dominus
September 16, 2003 14:52
Re: Interesting - [ Re: A user's experiences with GCC-3.4 snapshots]
Message ID:

Daniel Jacobowitz <>:
> To: Art Haas <>
> Cc:
> Subject: Re: A user's experiences with GCC-3.4 snapshots
> Message-ID: <>
> Mail-Followup-To: Art Haas <>,
> References: <>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> In-Reply-To: <>
> User-Agent: Mutt/1.5.1i
> On Tue, Sep 16, 2003 at 02:31:58PM -0500, Art Haas wrote:
> > $ cat try.c
> > #include <stdio.h>
> > int main() { extern void *setproctitle(); if(&setproctitle) return(0); else return(1); }
> This is not a valid way to test the existence of a function, and GCC is
> correct.  You are declaring that there is an external symbol named
> setproctitle, and asking for its address.  The C standard guarantees
> that the address of a function will never compare equal to NULL.
> So Perl needs to be fixed.

I thought the idea of this sort of test was that if there is no
setproctitle, the attempt to link the 'try' program will fail; the
'if' test isn't important, and the program, if it compiles and links,
will always return 0.

If I understand correctly, gcc-3.4 is smart enough to optimize out the
reference to 'setproctitle', so the resulting .o file doesn't refer to
'setproctitle', and the linker always succeeds.  If that's what's
going on, then something like this should be enough to defeat the
optimization and fix the problem:

#include <stdio.h>
int main() { extern void *setproctitle(); if(setproctitle == main) return(0); else return(1); }

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About