> > I'm surprised to hear you arguing that it is desirable for glibc's printf
> > implementation to segfault for a long-double with an unusual bit
> pattern.
>
> In which way is this different from printf("%s", (char*)1)?
I see a huge difference between passing an invalid pointer (your
printf("%s", (char*)1) example) and passing a valid pointer to
potentially invalid data (as in read(0,&ld,sizeof ld); printf("%Lf", ld)).
How is the programmer supposed to be able to tell if bytes read from
an untrusted source form a valid long double representation
if the library just crashes on invalid representations? It makes
perfect sense to me to have a smarter library that can aid
the programmer in rejecting invalid data from untrusted sources,
rather than falling over dead.
However, it is also true that it is impossible to get an invalid long
double by using the library to parse strings (such as strtold) or
by arithmetic manipulation of other valid long doubles; it is
only possible by interpreting raw bit patterns as a long double
(either by unions, type-punning, or other low-level memory
manipulations), which, as Andreas has pointed out, is undefined
by the C standard. So it is a quality of implementation issue,
not a bug; and a program that never reads arbitrary bytes
then handles them as a long double will never trip the
crash in glibc's long double handling.
Maybe a compromise would be making fpclassify smarter
at identifying invalid bit patterns, and throw the responsibility
back on the programmer - if a given bit pattern does not resolve
to one of FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL,
or FP_ZERO, then all bets are off when using that bit pattern
to any of the other library functions. At least it would then
be possible to write robust programs that do not invoke printf
with invalid long doubles, by using fpclassify to filter out
bad bit patterns from untrusted sources.
--
Eric Blake
--
View this message in context:
http://www.nabble.com/glibc-segfault-on-%22special%22-long-double-values-is-_ok_%21--tf3877642.html#a10990206
Sent from the Gnulib mailing list archive at Nabble.com.
