> From: owner-openssl-...@openssl.org On Behalf Of Robin Seggelmann via RT > Sent: Friday, 04 September, 2009 07:29 > Cc: openssl-dev@openssl.org
> On Sep 4, 2009, at 1:21 PM, Stephen Henson via RT wrote: > > A fair number of the casts seem to be unnecessary for example in > > RAND_bytes(), OPENSSL_malloc() and HMAC(). Do you get > warnings on your > > system without them? > > I used the same example in a server/client testprogram and > compiled it with the g++ compiler to be very pedantic. The > regular gcc doesn't complain if there are none at all, but > the g++ is nagging about missing casts. > I'm not looking at your specific cases but in general: Assuming you mean the compiler (cc1plus) and C++ CODE, not just the driver g++, the rules about types, conversions, and casts are subtly different than C. C++ is NOT exactly a superset of C as many people think, although it is close. Plus the GCC C compiler (cc1) is by default not very strict in its warnings; are you using at least -Wall ? In particular, in C you can implicitly convert from void* to any data pointer type (e.g. struct foo*); not in C++. (Similarly the const (or volatile) qualified forms.) In C, a declaration like int foo () means unspecified (but K&R1-compatible, no narrow or variadic) parameters, and a pointer to it is "compatible" with most int-returning function pointers and (thus) can be converted without cast. (Aside: the fact you can silently convert the pointer doesn't mean you can portably USE it; you must get the passed arguments close enough to right, and details vary across platforms.) In C++, int foo () means NO parameters, like int foo (void) (also in C), and is NOT compatible with say int bar (int). ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
