Thus spake Richard Levitte - VMS Whacker: > In message <[EMAIL PROTECTED]> on Wed, 17 Jul 2002 >13:33:09 -0500, Stephen Sprunk <[EMAIL PROTECTED]> said: > > stephen> I'd like to take on moving OpenSSL towards an autoconf > stephen> system. First of all, if anyone else is working on this, > stephen> please let me know :) > > Others have done that, but it's so far not been a hot topic. The > trouble with autoconf is that it's very sh-bound (or at least the end > result is), which means is largely Unix-bound, and it generates a > number of variables that are often difficult to keep up woth manually > no the systems where autoconf and sh don't exist or work badly.
Okay, I hadn't thought about VMS, Windows, etc. I'll come back when I have a better clue how to do it :) > stephen> Second, I'd like to move all OS-specific defines and includes to a > stephen> common place, such as <openssl/common.h>. This would hopefully > stephen> eliminate the need for <openssl/e_os2.h> entirely. Comments? > > So basically, you'd like e_os2.h to be renamed to common.h. Or did > you want to throw in the stuff that you find in e_os.h as well? Not exactly. There's a lot of OS-specific pollution in the source tree proper. A first target would be elimination of the OPENSSL_SYS_system family and replacing it with HAVE_feature and HAVE_header_h. > You need to understand that e_os.h is private to OpenSSL (it can mess > things up if used outside of OpenSSL) while e_os2.h is the public > part, so mixing them in the same file would be a bad idea. IMHO, stuff like this doesn't belong in the main sources: #ifdef OPENSSL_SYS_WINDOWS #define strcasecmp _stricmp #else #include <strings.h> #endif It's much easier for individual contributors to maintain this: #ifdef HAVE_STRINGS_H # include <strings.h> #endif And then the folks concerned with porting to a new OS would only have a single place to worry about: wherever the OS is translated into the HAVE_ macros. > The reason to stay away from things likt uint8 is that it isn't > standardised yet. On some compilers, __uint8 is available instead, on > others it's u_int8 or u_int_8... Basically, we would have to define > our own in terms of whatever we find out there... Here's something from the AES refence code; there are similar examples from most of the other crypto units: typedef unsigned long u32; typedef unsigned short u16; typedef unsigned char u8; On a variety of systems, you have no idea how long a "long" or an "int" is going to be, and that should be hidden in some generic header (like e_os[2].h) so that we can use uint32's in our code without worrying that we'll accidentally get a 16-bit or 64-bit int. ISO C95/99 define these pretty explicitly in <stdint.h>, and e_os[2].h should be able to hack around that on non-compliant systems. S -- Stephen Sprunk "So long as they don't get violent, I want to CCIE #3723 let everyone say what they wish, for I myself have K5SSS always said exactly what pleased me." --Albert Einstein ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
