Some functions in libc already take "out" parameters, by pointer; I'd
certainly rather see different notional information encoded by different
parameters, than a function returning tangled_mess_t.
> Using that model I guess we should also abandon NULL pointers
> to indicate errors...
NULL implying error is fine. But how could read--or anything which can
return 0 as a non-error--return NULL in case of error?
The actual problem here isn't the fact that an out-of-band value is
being used to indicate an error. Observe the complained-about case:
int result=read(...);
if (result==-1) return;
if (result<sizeof(something))
...
The "problem" is that the second if "looks" good, but that sizeof() is
unsigned. Here's what the compiler is thinking might happen:
* result < -1
and/or
* sizeof(something) >MAXINT
If both could happen, the compiler can't possibly do what you "mean"
with a signed, or an unsigned, comparison instruction in all cases.
So it warns you. It might be appropriate to suppress the warning
if sizeof() doesn't use its high bit (known at compile time) and
just go with a signed comparison; likewise, if I'd returned on
result<0, it could go with an unsigned comparison. But in
general, you're asking a lot when you do a signed/unsigned
comparison, and a warning really is appropriate.
I'd just as soon use the macro someone already suggested, and pray
sizeof() never returns >MAXINT...
Keith