ben> No, no - rid the world of evil casts!
In principle, I agree. However, there are technical reasons to see
them still... See below.
ben> > Was there ever a concensus on how this should be handled? Go with
ben> > unsigned everywhere?
ben>
ben> Go with what's right everywhere, surely?
Right. But about unsigned vs. a default, most standards I've seen
seem to say the API should have "char" unless there's a very specific
reason to have "unsigned char" in the interface. This is, of course,
a matter of taste. Personally, I've nothing against going "unsigned
char" (or "unsigned" whatever) everywhere, but then we hit problems
with functions like, for example, strlen(), who do no declare the
parameters "unsigned". So, on the other hand, we could remove
"unsigned" everywhere, at least with "char", but in that case, I won't
swear we have the same functionality everywhere. I haven't looked too
closely, but I wouldn't be surprised if there are places where things
are done a byte (a "char") at a time, and where sign extension (think
signed char to signed int...) might kill everything.
Considering this, I see no way of getting completely rid of casts, so
I work toward trying to minimise them.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
