Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 82.94.239.5 cause and error)
Date: Fri, 15 Jun 2007 13:54:18 +0200 (CEST)
To: PHP Developers Mailing List <internals@lists.php.net>
Message-ID: <alpine.DEB.0.98.0706151340161.4623@kossu.ez.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8
Subject: snprintf/var_export issues
From: derick@php.net (Derick Rethans)

Hello,

While testing a bit of code under a different locale (de_DE) we found 
that var_export() uses a , for representing floating point decimal 
separators. As var_export() is supposed to generate "valid PHP code" 
there is now a bug in this function.

While looking into this, I found that internally it uses the following 
call:

php_printf("%.*G", (int) EG(precision), Z_DVAL_PP(struc));

However, the G modifier, unlike F, is locale-aware and will happily 
create "5,12" as a "valid PHP float". This of course does not parse. I 
expected the uppercase G to be locale-insensitve and the lowercase g to 
be locale-sensitive. However, looking at the code it only switched 
between E and e. The g/G modifier as is implemented now does not seem to 
have any locale-insensitive option. The difference between "f" and "g" 
is that g/G is smarter regarding appending 0's. Trailing zeroes are not 
wanted when rendering a float as "valid PHP code" (as it looks different 
than when it was written in the application).

I see a few options to address this:

1. Change "G" to be locale-insensitve.

   We can't really do that as it's also use in _convert_to_string.

2. Add a new modifier "H" or "L" that is like G, but 
   locale-insensitive.

3. Change "g" to be locale-insensitve, as this one does not seem to be 
   used anywhere in the code base.


I think we should pick option 2, find another modifier letter as it 
won't impact anything else.


Notes:

- _build_trace_args (from Zend/zend_exceptions.c) seems also to be 
  affected, as it uses the G modifier to build argument lists as string 
  for exception traces. So now it uses the , to separate arguments AND 
  as float decimal sep in case of a de_DE locale.


regards,
Derick


-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org