[PHP-INTERNALS] snprintf / ap_php_snprintf, %lld, gcc versions?

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.

regards,
Derick

That doesn't seem to be the case. The library is built with

cc -I. -I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3 -DPHP_ATOM_INC -I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/include -I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/main -I/usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/Zend -I/usr/local/include/php/TSRM -I/usr/local/include -DHAVE_CONFIG_H -O -pipe -prefer-pic -c /usr/ports/sysutils/pecl-statgrab/work/Statgrab-0.3/statgrab.c -o statgrab.o >/dev/null 2>&1

and when I replace "-o statgrab.o >/dev/null 2>&1" with "-E" I see:

# 65 "/usr/local/include/php/main/snprintf.h"
int ap_php_snprintf(char *, size_t, const char *, ...) __attribute__ ((format(printf, 3, 4)));

and the macro calls expanded to use ap_php_snprintf().

Plus, this program works on the machines where the Statgrab extension
produces "%ld":

#include <stdio.h>

int
main (int argc, char **argv)
{
char tmp[256];
int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", 127LL);
printf("strlen (%s) == %d\n", tmp, tmp_len);
return 0;
}

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

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

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.
Yup, I did.