Re: using the interfaces in ctype.h

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> Indeed, however the current implementation doesn't even try to
> "detect" or "distinguish" EOF, and indeed passing EOF without casting
> it properly and/or masking will result in an out-of-bounds array
> access in the current implementation.

Look closer.  The object indexed inside the macro is _one past_ the
base of the array object being indexed; this is done specifically to
support EOF as an argument.

>> Anyway, the onus falls on the caller to ensure that they don't pass
>> invalid values; otherwise the implementation is allowed to do
>> anything at all.
> However I would hope that it is in the best interests of NetBSD to
> provide a _safe_ implementation, not just a minimally correct one.

But what does "safe" mean?  In this context, I don't think it means
"take out-of-range values and silently smush them into in-range
values".  Ideally, I'd say, it would mean "drop core when passed
anything out-of-range" (and I don't mean "drop core or access something
random, depending on the arg and how memory happens to be laid out").

However, that's expensive enough that I for one am willing to accept
the lessened error checking for the sake of performance of correct code.

>> Since masking inside the implementation would violate the
>> requirement to distinguish EOF from UCHAR_MAX, it's good that NetBSD
>> doesn't do that.
> Huh?  That makes no sense whatsoever.

Makes sense to me.  Passing EOF to isspace() is semantically different
from passing UCHAR_MAX (even if they happen to return the same value),
so it's just as well they aren't conflated.

> What do you think the current NetBSD implementation does when given
> EOF anyway?

Returns _C_ctype_[0] & _S, which is zero.  UTSL.

> How about when it's given a signed integer variable that has been
> assigned the value of EOF?

Returns _C_ctype_[0] & _S, which is zero.  UTSL.

> How about any other negative number which some user might have
> thought to be a useful way of extending the error reporting possible
> in such a situation?

Either zero, _S (which is 0x08), or a segfault, depending on the
particular negative number and the contents of other memory.  Is this a
problem?  Pass invalid arguments to library calls and you can expect
misbehaviour.  It is no part of libc's mandate to detect all possible
invalid calls, especially when it means a substantial performance hit.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B