Also, forgot to add. Earlier in the day I noticed various web applications that use number_format() were returning either 0, or random garbage such as:

0.F0
0.:;
0,0;

etc.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I can't duplicate this. Tried several different GCC versions to no avail.

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Joey, it doesn't crash... so you can not make a backtrace...

Anyway, this should be fixed in the latest CVS, so please try the snapshot.

The latest stable CVS snapshot does not work.  I can also confirm number_format() working in PHP 4.3.0 on Gentoo, but not working in PHP 4.3.2 on Gentoo.

I'm betting that this is related to that gcc bug that 
breaks the modf() call in glibc. It's cropped up on gentoo 
systems before, and usually happens when your 
CFLAGS/CXXFLAGS are set to something like '-march=pentium4 
-O3'. Use pentium3 or -mhost=i686 instead. 
 
See http://bugs.php.net/bug.php?id=22887 for details. 
 
J 
 
 

I compiled the snapshot, no compiler optimizations, and I enabled debugging.  My GCC version is:

gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice).  Perhaps it's propolice causing it? As of PHP 4.3.1 though, compiled with propolice, everything worked fine. I still get the same problem with number_format() with the snapshow from today.

russ@milton:~/php4-STABLE-200306031330/sapi/cli$ ./php -r 'echo number_format(4000,2); echo "\n";'
0.00
russ@milton:~/php4-STABLE-200306031330/sapi/cli$ ./php -r 'echo number_format(0,2); echo "\n";'
0.00
russ@milton:~/php4-STABLE-200306031330/sapi/cli$ ./php -r 'echo number_format(230,2); echo "\n";'
0.00
russ@milton:~/php4-STABLE-200306031330/sapi/cli$ ./php -r 'echo number_format(234440,2); echo "\n";'
0.00
russ@milton:~/php4-STABLE-200306031330/sapi/cli$ ./php -r 'echo number_format("234440",2); echo "\n";'
0.00
russ@milton:~/php4-STABLE-200306031330/sapi/cli$ gdb --args ./php -r 'echo number_format("234440",2); echo "\n";'

To make absolutely sure I'm not doing something different, I compiled PHP 4.3.1 again, the same way I compiled 4.3.2 and the daily SNAPSHOT, these are the results I get:
russ@milton:~/php-4.3.1/sapi/cli$ ./php -r 'echo number_format(500); echo "\n";'
500
russ@milton:~/php-4.3.1/sapi/cli$ ./php -r 'echo number_format(500); echo "\n";'
500
russ@milton:~/php-4.3.1/sapi/cli$ ./php -r 'echo number_format(7500); echo "\n";'
7,500
russ@milton:~/php-4.3.1/sapi/cli$ ./php -r 'echo number_format(7500,2); echo "\n";'
7,500.00

Obviously since it doesn't crash I can't bt on the core, but I set a breakpoint at the first call to spprintf which appears to be the major difference in _php_math_number_function() in math.c between 4.3.1 and 4.3.2.  It breaks at the first call which is made from _php_math_number_function().

russ@milton:~/php4-STABLE-200306031330/sapi/cli$ gdb --args ./php -r 'echo number_format("234440",2); echo "\n";'
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) break spprintf
Breakpoint 1 at 0x8128f55: file /home/russ/php4-STABLE-200306031330/main/spprintf.c, line 641.
(gdb) run
Starting program: /home/russ/php4-STABLE-200306031330/sapi/cli/php -r echo\ number_format\(\"234440\",2\)\;\ echo\ \"\\n\"\;

Breakpoint 1, spprintf (pbuf=0xbffff3a8, max_len=0, format=0x8183b58 "%.*f") at /home/russ/php4-STABLE-200306031330/main/spprintf.c:641
641             va_start(ap, format);
(gdb) bt
#0  spprintf (pbuf=0xbffff3a8, max_len=0, format=0x8183b58 "%.*f") at /home/russ/php4-STABLE-200306031330/main/spprintf.c:641
#1  0x080cb73a in _php_math_number_format (d=234440, dec=2, dec_point=46 '.', thousand_sep=44 ',')
    at /home/russ/php4-STABLE-200306031330/ext/standard/math.c:997
#2  0x080cbd1c in zif_number_format (ht=2, return_value=0x81ee2fc, this_ptr=0x0, return_value_used=1)
    at /home/russ/php4-STABLE-200306031330/ext/standard/math.c:1101
#3  0x0816d0a8 in execute (op_array=0x81edf5c) at /home/russ/php4-STABLE-200306031330/Zend/zend_execute.c:1606
#4  0x08151f13 in zend_eval_string (str=0xbffff97d "echo number_format(\"234440\",2); echo \"\\n\";", retval_ptr=0x0,
    string_name=0x81a88b4 "Command line code") at /home/russ/php4-STABLE-200306031330/Zend/zend_execute_API.c:636
#5  0x08173613 in main (argc=3, argv=0xbffff804) at /home/russ/php4-STABLE-200306031330/sapi/cli/php_cli.c:859
#6  0x400b2767 in __libc_start_main () from /lib/libc.so.6
(gdb)

Let me know if you need anything else. I can provide a shell with access to compiler and sources if you'd like.

I recompiled my glibc, I was unaware it was compiled at -O3, I was pretty certain I had specified it myself to -O2 and pentium3 only, maybe I hit it up accidentally during an emerge  -u world.  

Once I compiled it with -O2, number_format() began working again.

I have downloaded the latest stable version 4.3.2 and the issue with 0 being returned has not been fixed!

Is it possible someone could recompile the code for Windows distribution?

Thank you very much...

Max

This is Max. The format_number is working after all.

It was something I missed in the code. Was passing the parameter w/o ($)

My bad!