RE: [PHP-DEV] snprintf defined as ap_php_snprintf
| From: | Jeff Olhoeft | Date: | Thu, 03 Feb 2005 22:18:40 +0000 |
| Subject: | RE: [PHP-DEV] snprintf defined as ap_php_snprintf | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-14602@lists.php.net to get a copy of this message | ||
On Thu, 3 Feb 2005, Derick Rethans wrote:
> > > > Is this a deliberate change? Is there some way to tell configure to
> > > > use the system snprintf instead of the PHP version?
> > >
> > > You should always been using the ap_php_snprintf() one as that has an
> > > extra modified %F for non-locale aware number formatting. To make your
> > > extension work, make sure to include main/snprintf.h.
> >
> > I'm afraid I might not have been clear. In 4.3.10, php.h includes
> > snprintf.h, which defines snprintf as ap_php_snprintf. Unfortunately,
> > ap_php_snprintf is failing, causing the module to crash. If I force it
> to
> > use glibc's snprintf, everything works fine. Unfortunately,
> ap_php_snprintf
> > isn't an option right now, and I'm wondering what is the cleanest way to
> > insure that the system snprintf is used.
>
> You can't do that actually.
Is it necessary to override the system snprintf? This is a potential trap
for the unwary programmer. It took us a fair amount of digging to discover
that this was happening. I haven't found any documentation that warns that
snprintf might behave differently then one is used to.
> What fails in ap_php_snprintf? We need to
> fix that instead.
I'm afraid I've not been able to pin-point the problem more then that. The
target is an embedded system with limited memory, so debugging can be a
challenge at times. Looking at my original message, I realize that I forgot
to mention that the crash occurs only in mod_php, not the stand alone
excutable of php.
> (And always CC the mailinglist).
Ack, sorry about that.
Thanks,
Jeff