Peter Bex <peter....@xs4all.nl> 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 co...@ccil.org 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 _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
