ctype bug

[Joerg Sonnenberger]

On Wed, Jul 06, 2005 at 06:31:55PM -0700, Matthew Dillon wrote:
>     Focusing on making things fast rather then making things correct is just
>     about the worst type of programming mistake a person can make.  I see
>     it all the time, and that sort of programming inevitably leads to the
>     most problems down the line.

This whole discussion just proves how wrong the original change was.
I don't want to discuss whether it was intentional or accidential, I
think more in line of the latter. But since it made at least one not
totally clueless hacker believe that it is save to pass chars to the
ctype functions, it didn't increase the robustness of the code at all.
How many programs have you written in the past decade based on the
assumption that passing chars to isprint is save? How many of those are
used on platforms other than FreeBSD? Now think whether making libc more
robost is worse hiding a possible serious flaw in a lot of programs.

I've commited a change to allow GCC to *warn* about this, if anyone ignores
the warnings, they are on there own.

I also want to point out how many problems have resulted from other safety
belts. There was a discuss on the NetBSD a few weeks ago, about GCC changing
printf("%s", s) into fputs(stdout, s). That's perfectly legal according to
ISO C, but doesn't work on BSD derived systems for s == NULL. Sure, printing
(null) makes things easier, but programmers tend to depend on such behaviour.
It's one of the reason why so much software is broken when ported first from
Linux, e.g. because glibc's malloc is more forgiving. It's also a reason why
portability to RISC architectures is such a hassle, since the most common
architecture today doesn't enforce any alignment.

Silently turning invalid inputs into anything but error conditions does have
*more* negative impact in the short and in the medium term than it fixes.

Joerg