jmacd> Using void* is not very attractive, because you can't perform pointer
jmacd> arithmetic on the type, because it is not clearly a byte-addressable
jmacd> segment of data.
That in itself isn't hard to solve, just use some local variables of
some appropriate type and give them the pointers that are to be
manipulated. But other than that, you're quite correct.
jmacd> Overall, I think it is safer to use an unsigned character
jmacd> representation, and use casts to (char*) when neccesary.
Scream, Ben, scream :-).
jmacd> Since the library does lots of manipulations on things that are
jmacd> sometimes strings, but mostly to be treated as binary data,
jmacd> this makes sense. There are few good reasons to treat
jmacd> characters as signed, except for the system libraries, and
jmacd> there are good reasons to keep things unsigned.
Binary data is as well a good reason to use void *, except for the
slight hassle to have extra temporaries so pointer arithmetics can be
carried out... But we're picking nits needlessly at this point...
jmacd> A common programming mistake is to use a signed character to
jmacd> index an array from its origin. Only recently has egcs begun
jmacd> warning about these expressions, and its very annoying to track
jmacd> down bugs like that.
And I think you just answered to the question why GCC complains about
those subscripts in bn_print.c, obj_dat.c, v3_x509.c, v3_conf.c and
v3_utl.c that Ralf (and others) told us about. In all those cases,
the character that is given to isxxx() is a char, not a unsigned char.
--
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]
