Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14606 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28193 invoked by uid 1010); 3 Feb 2005 22:56:29 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 28177 invoked from network); 3 Feb 2005 22:56:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Feb 2005 22:56:29 -0000 X-Host-Fingerprint: 83.97.50.139 jan.prima.de FreeBSD 4.6-4.9 Received: from ([83.97.50.139:2566] helo=jan.prima.de) by pb1.pair.com (ecelerity HEAD (r4105:4106)) with SMTP id 32/DC-10528-C1CA2024 for ; Thu, 03 Feb 2005 17:56:29 -0500 Received: from BAUMBART (p508EB758.dip.t-dialin.net [::ffff:80.142.183.88]) (IDENT: HydraIRC, AUTH: LOGIN tobi) by jan.prima.de with esmtp; Thu, 03 Feb 2005 22:56:24 +0000 Date: Thu, 3 Feb 2005 23:56:05 +0100 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <189252242.20050203235605@marcus-boerger.de> To: Jeff Olhoeft CC: 'Derick Rethans' , 'PHP Developers Mailing List' In-Reply-To: <000601c50a3e$50cf9a40$54160a0a@ATLANTIC> References: <000601c50a3e$50cf9a40$54160a0a@ATLANTIC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] snprintf defined as ap_php_snprintf From: helly@php.net (Marcus Boerger) Hello Jeff, Thursday, February 3, 2005, 11:18:40 PM, you wrote: > 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, Well the problem is thatlots of systems are provide c libs that have very big memory problems that result in hige security risks or are simply not conforming to ISOc99 standatd which we require. One of the biggest problems is [v][s|f][n]printf() since we are focused on outputting something. -- Best regards, Marcus mailto:helly@php.net