http://qs1969.pair.com?node_id=11122413


in reply to Re^5: Influencing the Gconvert macro
in thread Influencing the Gconvert macro

Ok, the main calculation in the perl source is I think this statement from sv.c:

/* Determine the buffer size needed for the various * floating-point formats. * * The basic possibilities are: * * <---P---> * %f 1111111.123456789 * %e 1.111111123e+06 * %a 0x1.0f4471f9bp+20 * %g 1111111.12 * %g 1.11111112e+15 * * where P is the value of the precision in the format, or + 6 * if not specified. Note the two possible output formats +of * %g; in both cases the number of significant digits is < += * precision. * * For most of the format types the maximum buffer size ne +eded * is precision, plus: any leading 1 or 0x1, the radix * point, and an exponent. The difficult one is %f: for a * large positive exponent it can have many leading digits +, * which needs to be calculated specially. Also %a is slig +htly * different in that in the absence of a specified precisi +on, * it uses as many digits as necessary to distinguish * different values. * * First, here are the constant bits. For ease of calculat +ion * we over-estimate the needed buffer size, for example by * assuming all formats have an exponent and a leading 0x1 +. * * Also for production use, add a little extra overhead fo +r * safety's sake. Under debugging don't, as it means we're * more likely to quickly spot issues during development. */ float_need = 1 /* possible unary minus */ + 4 /* "0x1" plus very unlikely carry */ + 1 /* default radix point '.' */ + 2 /* "e-", "p+" etc */ + 6 /* exponent: up to 16383 (quad fp) */ #ifndef DEBUGGING + 20 /* safety net */ #endif + 1; /* \0 */

.. after which if we are subject to locale it goes and checks the actual length of the utf8 representation of the radix point and adjusts that "+ 1" for the default. The above adds up to 35, which is pretty close to the difference between 91 and 127.

The origin of the gcc warning looks like it might be gimple-ssa-sprintf.c or a close relative, in which case the "#define target_mb_len_max() 6" may well explain the difference between 127 and 133.

So this looks pretty safe to me - and you'd certainly need a debugging perl to get close to exercising the limits.

That just leaves the question of whether we can give the compiler enough hints for it to come to the same conclusion, or whether we'd only be able to shut it up with a sledgehammer preprocessor directive.

Hugo