|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66674 Invalid printf() conversion code in json.c (twice)
Submitted: 2014-02-08 12:18 UTC Modified: 2014-02-08 14:35 UTC
From: tom at bignm dot com Assigned:
Status: Not a bug Package: Compile Warning
PHP Version: 5.4.25 OS: Ubuntu Linux 11.04
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
16 - 8 = ?
Subscribe to this entry?

 [2014-02-08 12:18 UTC] tom at bignm dot com
When compiling PHP 5.4.25 two compilation warnings are displayed indicating an invalid printf() conversion code 'k' being used. On lines 408 and 619 inside a spprintf() calls, the following lines are found in source file 'json.c':

409: int l = spprintf(&tmp, 0, "%.*k", (int) EG(precision), d);
619: len = spprintf(&d, 0, "%.*k", (int) EG(precision), dbl);

My suspicion is that the conversion code should be 'e', 'f' or 'g' instead of 'k' since the value seems to be a double being processed in both cases with a fixed precision.

While only a warning, this can certainly cause invalid floating point values to be returned, possibly even causing segmentation faults in spprintf().

Test script:
Not needed.

Expected result:
Hopefully somebody will fix the source who knows which proper printf() conversion code to use.

Actual result:
Here's the 'make' line and the compiler's output for the file 'json.c':

/bin/bash /usr/local/src/php-5.4.25/libtool --silent --preserve-dup-deps --mode=compile cc  -Iext/json/ -I/usr/local/src/php-5.4.25/ext/json/ -DPHP_ATOM_INC -I/usr/local/src/php-5.4.25/include -I/usr/local/src/php-5.4.25/main -I/usr/local/src/php-5.4.25 -I/usr/local/src/php-5.4.25/ext/date/lib -I/usr/local/src/php-5.4.25/ext/ereg/regex -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/local/src/php-5.4.25/ext/mbstring/oniguruma -I/usr/local/src/php-5.4.25/ext/mbstring/libmbfl -I/usr/local/src/php-5.4.25/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/local/src/php-5.4.25/ext/sqlite3/libsqlite -I/usr/local/src/php-5.4.25/TSRM -I/usr/local/src/php-5.4.25/Zend    -I/usr/include -g -O2 -fvisibility=hidden  -c /usr/local/src/php-5.4.25/ext/json/json.c -o ext/json/json.lo 
/usr/local/src/php-5.4.25/ext/json/json.c: In function 'json_escape_string':
/usr/local/src/php-5.4.25/ext/json/json.c:408:6: warning: unknown conversion type character 'k' in format
/usr/local/src/php-5.4.25/ext/json/json.c: In function 'php_json_encode':
/usr/local/src/php-5.4.25/ext/json/json.c:619:6: warning: unknown conversion type character 'k' in format


json-invalid-printf-conversion-type-k-patch (last revision 2014-02-08 12:24 UTC by tom at bignm dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-02-08 12:59 UTC]
-Status: Open +Status: Not a bug
 [2014-02-08 12:59 UTC]
k is a custom modifier that prints a floating point number without taking locales into consideration.

Is there some way to teach gcc about custom printf modifiers?
 [2014-02-08 13:54 UTC] tom at bignm dot com
Okay, a custom modifier (conversion code) is wonderful. However, these need to be registered with the function 'register_printf_function()', which is nowhere to be found in the source code that I could find with grep. Unless another rarely used mechanism is in place to register this new code, it becomes pretty obvious that this is definitely a bug (intentional or not).
 [2014-02-08 14:05 UTC]
We don't use the libc *printf functions, but have custom implementations. See for example, which is used by (v)spprintf, and, which is used by (v)(a)s(n|l)printf.
 [2014-02-08 14:35 UTC] tom at bignm dot com
Okay! So the spprintf() function is totally a custom function. I find it strange that the gcc compiler would apply "printf()" conversion code warning heuristics to a custom function. You may want to check out how your custom function is being declared/defined in the source and/or headers so that gcc won't apply standard C library printf() conversion code heuristics to it.
 [2014-02-08 15:24 UTC]
We explicitly declare spprintf (and all other printf-like functions) using __attribute__((format(...)), see e.g. After all we *do* want to have the checks in general, they're just wrong in these particular cases with custom modifiers.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Thu Nov 30 02:01:27 2023 UTC