Re: [Chicken-hackers] [PATCH] Fix #566 and simplify/improve flonum printing code

[John Cowan]

Peter Bex <address@hidden> scripsit:

> However, I've tested all three Windows builds, and they all behave
> equally well (or better) with s[n]printf() instead of gcvt().  We no
> longer have a MSVC build, so the original problem probably was there,

As of Visual C++ 2005, Microsoft deprecated all the functions in the C
Runtime Library that aren't part of ISO C.  So snprintf, which is part
of Posix but not ISO C, appears as _snprintf.  This is a general problem
which we'll have to solve if we ever want a VC++ build.  In some cases,
like gcvt, the original function survives in deprecated form, but _gcvt
is recommended.  This is all in the name of avoiding namespace pollution,
a silly concern on Windows with its monstrous <windows.h> file.

In both GNU libc and newlib, gcvt just calls sprintf.

> I've also taken the opportunity to convert sprintf into a checked
> snprintf.  I'm not 100% sure but I don't think this requires a CVE
> since you can't easily (at all?) cause over 4096 flonum digits to
> get printed, 

It would be nonsense to do so anyway:

#;1> (parameterize ((flonum-print-precision 4095)) (print 1.1))
1.100000000000000088817841970012523233890533447265625

All those low-order digits represent the triumph of precision
over accuracy.

I suppose some day we could integrate MPFR into the numbers egg, though.

-- 
John Cowan    address@hidden    http://ccil.org/~cowan
Rather than making ill-conceived suggestions for improvement based on
uninformed guesses about established conventions in a field of study with
which familiarity is limited, it is sometimes better to stick to merely
observing the usage and listening to the explanations offered, inserting
only questions as needed to fill in gaps in understanding. --Peter Constable