I'd like to know about the intended behavior on 64bit architecture
machines.
in many places, it seems to me that "unsigned long" is assumed to be
32bit. For example, in des.h and blowfish.h, it seems that the code
assume that unsigned long is 32bit. otherwise, we can't pass a pointer
to bytestream into bf_encrypt and encrypt/decrypt functions become less
useful (NOTE: I understand alignment constraint difference in pointer
cast - please put that aside for now).
/* this one does not work if we have 64bit unsigned long */
char *p = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
char q[8];
BF_KEY k;
des_encrypt((BF_LONG *)p, (BF_LONG *)q, &k);
it is also true for internal source code level. it is assumed that
unsigned long is 32bit. I had troubles making openssl work on
alpha and possibly sparc64 (on top of NetBSD).
also, it bothers me that include files has many #ifdefs. if some third
party application defines a symbol which is used in openssl headers,
the API openssl headers present will get different from the real
API in the compiled binary.
I'm trying to go through all of these and rewrite as much as possible,
including:
- nuke all visible #ifdef in headers in include/openssl, to get
stable behavior. #ifdef is in local headers (des_locl.h) or
Makefiles.
- use types like uint32_t or u_int32_t, when we want a type with
fixed size. if these types are not available, find them at
configuration time.
it may involve some updates into build framework (like Configure and
Makefile.ssl).
is it worth a effort, or do I misunderstand something?
itojun
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
