Re: Style question: comparison between signed and unsigned?

david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
24 Sep 1997 11:41:57 -0700


In article <linux.kernel.yv2wwk7etir.fsf@i44d2.i-have-a-misconfigured-system-so-shoot-me>,
Ulrich Drepper <drepper@ipd.info.uni-karlsruhe.de> wrote:
>"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
>
>> The fact of the matter is, by having the compiler issue these warnings,
>> it makes folks much more likely to ignore *all* compiler warnings, since
>> so many of them will be false positives.
>
>If somebody behaves like this it is her/his own fault and I certainly
>won't trust the program.

Umm, there is some interesting reading out there about how people
burn out when there's too much information coming in. Admittedly,
programming isn't quite the same as sitting in the OC of a nuclear
plant trying to spot the bad light in the forest of good lights,
but the concept is the same.

> int n = read (...);
>
>is of course plainly wrong. `read` returns ssize_t.

In your library, yes, but there's a lot of prior art that has read()
returning an int, and people cheerfully assigning the results of
read() into an int. If a modern C compiler can't properly, and
silently, deal with (int) := (ssize_t), it's badly broken, and
it will break no matter how much you try to warp the library to
fit the psychotic compiler of the week.

____
david parsons \bi/ oh my god, C has transmorgified into Pascal!
\/