snprintf/var_export issues

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