# [EMAIL PROTECTED] / 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
