Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15628
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sun, 27 Mar 2005 00:58:44 +0100
To: internals@lists.php.net
Message-ID: <20050326235844.GA6613@isis.sigpipe.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Subject: snprintf / ap_php_snprintf, %lld, gcc versions?
From: neuhauser@sigpipe.cz (Roman Neuhauser)

Hello,

I'm having a puzzling problem with %lld conversion handling
in ap_php_snprintf, and it seems to be gcc version-dependent.

I found this problem through Statgrab, which has this macro:

#define PHP_SG_ADD_LLVAL(rtz, key, val)	{	\
	char tmp[256];	\
	int tmp_len = snprintf((char *)&tmp, sizeof(tmp) - 1, "%lld", val);	\
	add_assoc_stringl_ex(rtz, key, sizeof(key), tmp, tmp_len, 1);	\
}

main/snprintf.[hc]:

#define snprintf ap_php_snprintf
PHPAPI int ap_php_snprintf(char *buf, size_t len, const char *format,...)

The above macro works fine on some machines, and produces "%ld" on others.
I have these configurations:

working: two FreeBSD-4 boxes (cc is 2.95.4), one of these has PHP 4.3.9
installed, the other one 5.0.3

broken: FreeBSD-5 (cc is 3.4.2 [FreeBSD] 20040728), PHP 4.3.10,
RHEL3 (cc is 3.2.3 20030502 (Red Hat Linux 3.2.3-42)), PHP 4.3.10

I don't see much in common between the broken installs except the major
versions of the compilers.

Has anyone else seen this?

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991