[Fwd: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c]

I think the C behaviour is correct and we need to make a (hopefully)
slight adjustment to the pear installer code.

Ilia? Greg?
Any comments?

This patch breaks PEAR phar install on 64bit.

From what I can see in the source code, it compares data in the
phar with
the result of sprintf("%u"..), which is different on 32bit and
64bit because of this patch.
Either phar should be changed to detect this situation or this
patch should be reverted.
-------- Original Message --------
Subject: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c
Date: Sun, 03 Jun 2007 09:11:52 -0000
From: Brian Shire shire@php.net
To: php-cvs@lists.php.net
shire Sun Jun 3 09:11:52 2007 UTC
Modified files: /php-src/ext/standard
formatted_print.c Log:
Change printf %u behavior so that it does not truncate numbers
at 32-bits. (Reported by Aditya Agarwal.)
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/
formatted_print.c?r1=1.100&r2=1.101&diff_format=u
Index: php-src/ext/standard/formatted_print.c
diff -u php-src/ext/standard/formatted_print.c:1.100 php-src/ext/
standard/formatted_print.c:1.101
--- php-src/ext/standard/formatted_print.c:1.100 Thu May 17
17:29:09 2007
+++ php-src/ext/standard/formatted_print.c Sun Jun 3 09:11:52 2007
@@ -16,7 +16,7 @@

+--------------------------------------------------------------------
--+
/
-/ $Id: formatted_print.c,v 1.100 2007/05/17 17:29:09 tony2001
Exp $ /
+/ $Id: formatted_print.c,v 1.101 2007/06/03 09:11:52 shire Exp $ /
#include <math.h> / modf() */
#include "php.h"
@@ -278,7 +278,7 @@
PRINTF_DEBUG(("sprintf: appenduint(%x, %x, %x, %d, %d, '%c', %d)
\n",
*buffer, pos, size, number, width, padding, alignment));

• magn = (unsigned int) number;

• magn = (unsigned long) number;
  /* Can't right-pad 0's on integers */
  if (alignment == 0 && padding == '0') padding = ' ';

--
Wbr, Antony Dovgal

Ilia Alshanetsky

Antony Dovgal wrote:

Ilia? Greg?
Any comments?

This patch breaks PEAR phar install on 64bit.

From what I can see in the source code, it compares data in the phar
with
the result of sprintf("%u"..), which is different on 32bit and 64bit
because of this patch.

Either phar should be changed to detect this situation or this patch
should be reverted.

Hi,

My only comment is I've already been forced to change a fully working
PHP_Archive 3 times because of bugfixes that broke BC in pack/unpack,
and I changed it to sprintf("%u") because it was the only way to ensure
that the behavior works the same way on 32-bit and 64-bit.

I would appreciate it if this is the last change of this nature that I
need to deal with :).

As for PHP_Archive, I'll try to figure out a solution but to be honest,
I'm not too keen on this, as sprintf("%u") was the only solution I found
last time. Perhaps dropping unpack() and rewriting it in userspace is
my only option <shiver>.

Thanks,
Greg

P.S. just to be clear, this is PHP_Archive we're talking about, not
phar. phar is a PHP extension that has no such problems as it does all
the unpacking internally, PHP_Archive is a userspace stream wrapper that
uses unpack()/sprintf("%u")