http://qs321.pair.com?node_id=11122366


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

If you can't or won't spend time in fixing compline/d_gconvert.U, the best approach will be to create your own Policy.sh which defined d_Gconvert exactly as you want it.

The -D argument might work, but I am always scared of interpolation when requiring quotes. The tricky parts are the callback units.

Setting this using env does not work.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^3: Influencing the Gconvert macro
by syphilis (Archbishop) on Sep 30, 2020 at 14:27 UTC
    If you can't or won't spend time in fixing compline/d_gconvert.U ...

    If I can fix it, then I will undertake to do so.
    At the moment, however, I have no idea how d_gconvert.U fits into "the scheme of things".
    AFAICS, it's not part of the perl source.

    ... but I am always scared of interpolation when requiring quotes

    I bothers me a bit, too. Although the configure option that I used seems to have done the trick, it wasn't exactly noiseless:
    In file included from sv.c:32:0: sv.c: In function ‘Perl_sv_vcatpvfn_flags’: config.h:909:39: warning: ‘%.*g’ directive writing between 1 and 133 b +ytes into a region of size 127 [-Wformat-overflow=] #define Gconvert(x,n,t,b) sprintf((b),"%.*g",(n),(x)) ^ perl.h:6791:13: note: in definition of macro ‘WITH_LC_NUMERIC_SET_TO_N +EEDED_IN’ block; + \ ^~~~~ sv.c:48:5: note: in expansion of macro ‘PERL_UNUSED_RESULT’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~~~~~~~~~~~ sv.c:48:24: note: in expansion of macro ‘Gconvert’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~ sv.c:13118:21: note: in expansion of macro ‘SNPRINTF_G’ SNPRINTF_G(fv, ebuf, sizeof(ebuf), precis) ^ config.h:909:39: note: assuming directive output of 132 bytes #define Gconvert(x,n,t,b) sprintf((b),"%.*g",(n),(x)) ^ perl.h:6791:13: note: in definition of macro ‘WITH_LC_NUMERIC_SET_TO_N +EEDED_IN’ block; + \ ^~~~~ sv.c:48:5: note: in expansion of macro ‘PERL_UNUSED_RESULT’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~~~~~~~~~~~ sv.c:48:24: note: in expansion of macro ‘Gconvert’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~ sv.c:13118:21: note: in expansion of macro ‘SNPRINTF_G’ SNPRINTF_G(fv, ebuf, sizeof(ebuf), precis) ^ In file included from /usr/include/stdio.h:862:0, from perlio.h:41, from iperlsys.h:50, from perl.h:3934, from sv.c:32: /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___ +sprintf_chk’ output between 2 and 134 bytes into a destination of siz +e 127 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from sv.c:32:0: config.h:909:39: warning: ‘%.*g’ directive writing between 1 and 133 b +ytes into a region of size 127 [-Wformat-overflow=] #define Gconvert(x,n,t,b) sprintf((b),"%.*g",(n),(x)) ^ perl.h:6791:13: note: in definition of macro ‘WITH_LC_NUMERIC_SET_TO_N +EEDED_IN’ block; + \ ^~~~~ sv.c:48:5: note: in expansion of macro ‘PERL_UNUSED_RESULT’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~~~~~~~~~~~ sv.c:48:24: note: in expansion of macro ‘Gconvert’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~ sv.c:13118:21: note: in expansion of macro ‘SNPRINTF_G’ SNPRINTF_G(fv, ebuf, sizeof(ebuf), precis) ^ config.h:909:39: note: assuming directive output of 132 bytes #define Gconvert(x,n,t,b) sprintf((b),"%.*g",(n),(x)) ^ perl.h:6791:13: note: in definition of macro ‘WITH_LC_NUMERIC_SET_TO_N +EEDED_IN’ block; + \ ^~~~~ sv.c:48:5: note: in expansion of macro ‘PERL_UNUSED_RESULT’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~~~~~~~~~~~ sv.c:48:24: note: in expansion of macro ‘Gconvert’ PERL_UNUSED_RESULT(Gconvert((NV)(nv), (int)ndig, 0, buffer)) ^~~~~~~~ sv.c:13118:21: note: in expansion of macro ‘SNPRINTF_G’ SNPRINTF_G(fv, ebuf, sizeof(ebuf), precis) ^ In file included from /usr/include/stdio.h:862:0, from perlio.h:41, from iperlsys.h:50, from perl.h:3934, from sv.c:32: /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___ +sprintf_chk’ output between 2 and 134 bytes into a destination of siz +e 127 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Of course, I probably should at least run make test before I start getting too excited about how successful it has been ;-)

    Cheers,
    Rob

      But it is dear hacker, it is! (free interpretation of Jethro Tull's "But you can Guru, You can" in the story of the Hare who lost his spectacles)

      Please see d_gconvert.U.

      Short summary, these units are parsed, selected and ordered according to the requirements of the perl source itself and than remodelled into the script that is called Configure.

      If you dare start the journey, read the README to start this early in the perl configuration process.


      Enjoy, Have FUN! H.Merijn

      I've seen such warnings in smoke logs a number of times, and tried to investigate at least a couple of times without success; I'd love (someone) to get to the bottom of it, at least to understand if it's a real problem (that needs to be fixed by increasing a buffer size).

      I've never seen anyone report an actual problem relating to the warning though.

      Hugo

        I'd love (someone) to get to the bottom of it, at least to understand if it's a real problem (that needs to be fixed by increasing a buffer size).

        I can verify that the "%.*g" formatting still works ok when the buffer size needs to be bigger than 127.
        For example, with this patched perl, perl -le 'printf "%.751g\n", 2 ** - 1074;' prints out all 751 mantissa digits correctly and displays the exact decimal rendition of the value 2 ** -1074.
        $ ./perl -I./lib -le 'printf "%.751g\n", 2 ** - 1074;' 4.94065... another 740 digits ...65625e-324

        Actually, I can add a little to that.
        I hacked the source to print out the size of the buffer, and I've just discovered that, so long as I ask for no more than 91 digits, the buffer size is 127 - which should be sufficient.
        But as soon as I ask for more than 91 digits, the buffer size is not displayed - indicating that the processing has switched to a different block.
        Incredibly, when I ask for more than 91 digits, I've also just now realized that the "%.*g" formatting works fine on Ubuntu-18.04 perls. That is, the bug exists only when I request 18 to 91 (inclusive) digits.
        If I request a number outside of that range, it works fine on a standard (unpatched) perl-5.32.0 on Ubuntu-18.04:
        $ perl -le 'printf "%.91g\n", 2 ** -1074;' 4.9406564584124654e-324 $ perl -le 'printf "%.92g\n", 2 ** -1074;' 4.94065645841246544176568792868221372365059802614324764425585682500675 +50727020875186529983636e-324
        So it looks to me that the concern surrounding the 127-byte buffer is unfounded, because the processing switches to a different block as soon as we ask for more than 91 digits.
        But I'm not prepared to claim that I've actually proved anything ;-)

        Cheers,
        Rob