@@ -254,9 +254,14 @@ yajl_gen_status
254254yajl_gen_integer (yajl_gen g , long long int number )
255255{
256256 char i [32 ];
257+ int len ;
258+
257259 ENSURE_VALID_STATE ; ENSURE_NOT_KEY ; INSERT_SEP ; INSERT_WHITESPACE ;
258- sprintf (i , "%lld" , number );
259- g -> print (g -> ctx , i , (size_t )strlen (i ));
260+ len = sprintf (i , "%lld" , number );
261+ if (len < 0 ) { /* highly unlikely, perhaps impossible */
262+ return yajl_gen_invalid_number ;
263+ }
264+ g -> print (g -> ctx , i , (size_t ) len );
260265 APPENDED_ATOM ;
261266 FINAL_NEWLINE ;
262267 return yajl_gen_status_ok ;
@@ -285,22 +290,28 @@ yajl_gen_status
285290yajl_gen_double (yajl_gen g , double number )
286291{
287292 char i [32 ];
293+ int len ;
294+
288295 ENSURE_VALID_STATE ; ENSURE_NOT_KEY ;
289296 if (isnan (number ) || isinf (number )) return yajl_gen_invalid_number ;
290297 INSERT_SEP ; INSERT_WHITESPACE ;
291- sprintf (i , "%.*g" , DBL_DIG , number ); /* xxx in theory we could/should use
292- * DBL_DECIMAL_DIG for pure
293- * serialization, but what about to
294- * JSON readers that might not be using
295- * IEEE 754 binary64 for numbers? */
298+ len = sprintf (i , "%.*g" , DBL_DIG , number ); /* xxx in theory we could/should
299+ * use DBL_DECIMAL_DIG for pure
300+ * serialization, but what about
301+ * to JSON readers that might not
302+ * be using IEEE 754 binary64 for
303+ * numbers? */
304+ if (len < 0 ) { /* highly unlikely, or even impossible? */
305+ return yajl_gen_invalid_number ;
306+ }
296307 /*
297- * xxx perhaps this should be controlled by a runtime-configurable
298- * option?
308+ * xxx perhaps forcing decimal notation should be controlled by a
309+ * runtime-configurable option?
299310 */
300311 if (strspn (i , "0123456789-" ) == strlen (i )) {
301312 strcat (i , ".0" );
302313 }
303- g -> print (g -> ctx , i , (size_t )strlen ( i ) );
314+ g -> print (g -> ctx , i , (size_t ) len );
304315 APPENDED_ATOM ;
305316 FINAL_NEWLINE ;
306317 return yajl_gen_status_ok ;
0 commit comments