Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 30 Mar 2005 17:21:54 +0200
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Message-ID: <20050330152154.GB53884@isis.sigpipe.cz>
References: <20050326235844.GA6613@isis.sigpipe.cz> <Pine.LNX.4.62.0503270749250.3162@localhost> <20050329113532.GA42955@isis.sigpipe.cz> <Pine.LNX.4.62.0503300954570.3371@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.62.0503300954570.3371@localhost>
User-Agent: Mutt/1.5.6i
Subject: Re: [PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions?
From: neuhauser@sigpipe.cz (Roman Neuhauser)

# derick@php.net / 2005-03-30 09:55:57 -0500:
> On Tue, 29 Mar 2005, Roman Neuhauser wrote:
> 
> > > > #define snprintf ap_php_snprintf
> > > > PHPAPI int ap_php_snprintf(char *buf, size_t len, const char *format,...)
> > > 
> > > For some reason the header file is not included then - that should be 
> > > fixed as our own (ap_php_snprintf) function should always be used which 
> > > is not gcc dependent.
> > 
> >     Turns out you are right, but probably not the way you expected:
> >     
> >     %lld is broken on the boxes where snprintf expands to
> >     %ap_php_snprintf(). The difference is in the installed
> >     include/php/main/snprintf.h file (present vs. missing
> >     HAVE_SNPRINTF check), at least between a pair of hosts I'm looking
> >     at right now.
> >     
> >     So now the question is: what is the best (least intrusive) way to
> >     make sure the system snprintf is used? #if 0 the snprintf macro?
> 
> Don't do that :)

    To be honest, at this point I don't trust ap_php_s*printf with my
    data.

    If ap_php_snprintf is meant as a drop-in replacement for snprintf,
    then I don't see what would break if I did exactly that (before
    recompiling all of PHP + extensions).

    I wound up putting #undef snprintf in the extencsion's header file,
    and that fixed it, but to be honest, I'm shitting bricks from fear
    that other parts of the installation are broken as well, and will
    break my code in totally unexpected places, and damage the data in
    new ways.
 
> >     BTW, perhaps the unconditional ap_php_snprintf use could be backed
> >     out until the function is mature enough to actually be an
> >     improvement? See also
> >     http://marc.theaimsgroup.com/?l=php-dev&m=110746124520191&w=2
> 
> No, we should not back it out, but fix our ap_php_snprintf function, but 
> it seems you already filed a bug about this which is assigned to Marcus.

    Yup, I did.
    
-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991