David Schwartz wrote: >> On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote: > >>> gcc 4.2 no longer allows function casting - which is used >>> rather heavily by >>> openssl. (To make things worse, it compiles but inserts abort() >>> statements >>> resulting in app crashes). > >> Ugh, I would've thought that flagging a compiliation error would make more >> sense rather that outputting bad code... > > It is perfectly reasonable (though certainly not optimal) for a compiler to > output bad code when the code it's compiling invokes undefined behavior.
Aren't they doing it when the code it's compiling _may_ invoke undefined behaviour on other platforms? This does not strike me as "perfectly reasonable". >>> You can see http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html >>> >>> for a discussion on the gcc devel list. >>> >>> Is there a fix to make OpenSSL compatible with gcc 4.2/4.3 yet? > >> No there isn't yet, some technique will be needed to make this >> still work by >> tweaking some of the macros. Does casting a function to (void *) >> first then >> the function cast work? > > Not if by work you mean anything more than accidentally happen to work on > some platforms. There is no reason a 'void (*) (struct bar *);' needs to be > even remotely like a 'void (*) (char *);'. Nevertheless, it is exactly like it on many processors. > OpenSSL should be fixed to cast the parameters, not the functions. Casting the functions gives you type-safety. Casting the parameters means you can have any old crap in the parameters and you don't find out at compile-time. > Look at this code: > > char * PEM_ASN1_read_bio(char *(*d2i)(),const char *name,BIO *bp,char **x, > pem_password_cb *cb, void *u); > > #define PEM_read_X509(fp,x,cb,u) (X509 *)PEM_ASN1_read( \ > (char *(*)())d2i_X509,PEM_STRING_X509,fp,(char **)x,cb,u) > > #define PEM_read_SSL_SESSION(fp,x,cb,u) (SSL_SESSION *)PEM_ASN1_read( \ > (char *(*)())d2i_SSL_SESSION,PEM_STRING_SSL_SESSION,fp,(char > **)x,cb,u) > > This is just wrong. A pointer to d2i_X509 and a pointer to d2i_SSL_SESSION > are of different types. You cannot cast them into a common type and then > write a function that can call either of them through such a pointer. > > The error is *NOT* from casting function pointers (like you must do to the > return from 'dlsym'). It's from casting a pointer to a function of one type > into a function of *another* type and then *calling* it through that > pointer. But it gets cast back to the correct type before it is called. These casts are done the way they are to get type-safety. Removing that option strikes me as a bad thing. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
