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