Re: snprintf / ap_php_snprintf, %lld, gcc versions?

From: Date: Wed, 30 Mar 2005 14:55:57 +0000
Subject: Re: snprintf / ap_php_snprintf, %lld, gcc versions?
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-15686@lists.php.net to get a copy of this message
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 :) > 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. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

« previous php.internals (#15686) next »