Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15686 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56804 invoked by uid 1010); 30 Mar 2005 14:56:09 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 56776 invoked from network); 30 Mar 2005 14:56:09 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 30 Mar 2005 14:56:09 -0000 X-Host-Fingerprint: 82.94.239.5 unknown Linux 2.5 (sometimes 2.4) (4) Received: from ([82.94.239.5:46926] helo=jdi.jdi-ict.nl) by pb1.pair.com (ecelerity HEAD r(5268)) with SMTP id 71/0B-22409-60EBA424 for ; Wed, 30 Mar 2005 09:56:06 -0500 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.12.11/8.12.11) with ESMTP id j2UEuZ4m014290 for ; Wed, 30 Mar 2005 16:56:35 +0200 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.12.11/8.12.11) with ESMTP id j2UEuVUB014273; Wed, 30 Mar 2005 16:56:31 +0200 Date: Wed, 30 Mar 2005 09:55:57 -0500 (EST) X-X-Sender: derick@localhost To: Roman Neuhauser cc: internals@lists.php.net In-Reply-To: <20050329113532.GA42955@isis.sigpipe.cz> Message-ID: References: <20050326235844.GA6613@isis.sigpipe.cz> <20050329113532.GA42955@isis.sigpipe.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at jci-ict.nl Subject: Re: [PHP-DEV] snprintf / ap_php_snprintf, %lld, gcc versions? From: derick@php.net (Derick Rethans) On Tue, 29 Mar 2005, Roman Neuhauser wrote: > > > #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? Don't do that :) > 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 -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org