Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15652
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 29 Mar 2005 13:35:32 +0200
To: Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
Message-ID: <20050329113532.GA42955@isis.sigpipe.cz>
References: <20050326235844.GA6613@isis.sigpipe.cz> <Pine.LNX.4.62.0503270749250.3162@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.62.0503270749250.3162@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-27 07:49:31 +0200:
> On Sun, 27 Mar 2005, Roman Neuhauser wrote:
> > I'm having a puzzling problem with %lld conversion handling
> > in ap_php_snprintf, and it seems to be gcc version-dependent.
> > 
> > I found this problem through Statgrab, which has this macro:
> > 
> > #define PHP_SG_ADD_LLVAL(rtz, key, val)	{	\
> > 	char tmp[256];	\
> > 	int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", val);	\
> > 	add_assoc_stringl_ex(rtz, key, sizeof(key), tmp, tmp_len, 1);	\
> > }
> > 
> > main/snprintf.[hc]:
> > 
> > #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?
    
    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

-- 
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