Quoting Richard Levitte - VMS Whacker ([EMAIL PROTECTED]):
> cjh> > No, no - rid the world of evil casts!
> cjh> > Go with what's right everywhere, surely?
> cjh> 
> cjh> That's difficult when system library calls are often variously
> cjh> and erroneously prototyped.  The alternative is wrappers
> cjh> "my_select(...)" or evil casts on those function calls only.
> cjh> Opinions?
> 
> Another solution (and I just checked this with a friend who knows the C
> standards pretty damn well) could be to use `void *' for any argument
> that is supposed to hold binary (non-text) data.  That would probably
> be better than the `unsigned char *' that keeps on haunting us,
> especially since any pointer will coerce implicitely to `void *', and
> `void *' will coerce implicitely to any other pointer type.

Using void* is not very attractive, because you can't perform pointer
arithmetic on the type, because it is not clearly a byte-addressable
segment of data.

> Either that, or review the current prototypes.  For example, I see no
> real reason for things like ASN1_STRING_set() to have an `unsigned
> char *' is string input argument...  `char *' would do just as well,
> and would leave us with less ambiguity (the third argument is pften
> generated with strlen(), which normally takes a `char *'...).

Overall, I think it is safer to use an unsigned character representation,
and use casts to (char*) when neccesary.  Since the library does lots of
manipulations on things that are sometimes strings, but mostly to be
treated as binary data, this makes sense.  There are few good reasons to 
treat characters as signed, except for the system libraries, and there are 
good reasons to keep things unsigned.  A common programming mistake is to 
use a signed character to index an array from its origin.  Only recently 
has egcs begun warning about these expressions, and its very annoying to 
track down bugs like that.

-josh
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to