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

# 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