Re: [openssl.org #2312] Function protos in 1.0.0a: unsigned long changed to size_t not so good for amd/x64, Itanium

Wed, 28 Jul 2010 15:35:38 -0700 

Hi:

Thanks for the quick reply.
You mentioned "...not meant to be binary compatible...for low-level APIs..". However, it could have been binary compatible had the size_t version of the function been given a new name, e.g., AES_ctr128_encrypt_sz(), while the old entry name had also been retained for the "unsigned long" version. If you're using GetProcAddress() to retrieve the function address out of the DLL, you've got to decide, based on SSL version, which function pointer var to associate with the func and which to use, on the fly. A bit tricky, perhaps. With C, you can't have two different prototypes for the same function, not to mention, how would you call one versus another?
Anyway, it's probably too late now, even if I could persuade you to change. There would still be some tricky func var switching required for versions 1.0.0, and 1.0.0a. Also, I haven't diff-ed all the function protos in SSL. So, you're saying you didn't do any "unsigned long" to "size_t" changes in the higher-level prototypes? 

JGS
----- Original Message ----- From: "Mounir IDRASSI via RT" <[email protected]> 
To: <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, July 28, 2010 8:03 AM
Subject: Re: [openssl.org #2312] Function protos in 1.0.0a: unsigned long changed to size_t not so good for amd/x64, Itanium 



 Hi,

As far as I know, OpenSSL 1.0 is not meant to be binary compatible with
OpenSSL 0.9.8x, at least for low-level APIs like the AES one you are
referring to.
So, as you suggest it, an application should know if it is using a 0.9.8
libeay32 or an 1.0 one, and depending on that it will use the correct
prototype.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

On 7/28/2010 3:02 PM, John Skodon via RT wrote:

Hi guys:
I'm probably wrong here, but it looks like you've changed some function prototypes, e.g., aes.h, in version 1.0.0a to "size_t" from "unsigned long" in 0.9.8o. 

E.g.,
0.9.8o, AES.H:
void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out,
  size_t length, const AES_KEY *key,
  unsigned char ivec[AES_BLOCK_SIZE],
  unsigned char ecount_buf[AES_BLOCK_SIZE],
  unsigned int *num);

1.0.0a, AES.H:
void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out,
  const unsigned long length, const AES_KEY *key,
  unsigned char ivec[AES_BLOCK_SIZE],
  unsigned char ecount_buf[AES_BLOCK_SIZE],
  unsigned int *num);
The eccentric LLP64 model of Microsoft Windows AMD64 and Itanium has "long" and "unsigned long" as 32-bits, and "size_t" as 64-bits. So, it would seem that code that called AES_ctr128_encrypt() compiled under 0.9.8o would push 32-bits less onto the stack on AMD/Itanium than code using the 1.0.0a headers.
Just about every other popular compiler model I can think of, primarily W32, Unix 32, and Unix 64 LP64 would not experience a problem.
If I'm correct, code calling these functions on AMD/x64 would need maybe two different function pointers defined for AES_ctr128_encrypt(), and on the fly switching between the two, depending on the version retrieved from LIBEAY32.DLL. 

Am I missing something here?

Thanks in advance for your help,
JGS



Hi guys:
I'm probably wrong here, but it looks like you've changed some function
prototypes, e.g., aes.h, in version 1.0.0a to "size_t" from "unsigned long" in 
0.9.8o.
E.g.,
0.9.8o, AES.H:
void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out,
* size_t length*, const AES_KEY *key,
unsigned char ivec[AES_BLOCK_SIZE],
unsigned char ecount_buf[AES_BLOCK_SIZE],
unsigned int *num);
1.0.0a, AES.H:
void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out,
* const unsigned long length*, const AES_KEY *key,
unsigned char ivec[AES_BLOCK_SIZE],
unsigned char ecount_buf[AES_BLOCK_SIZE],
unsigned int *num);
The eccentric LLP64 model of Microsoft Windows AMD64 and Itanium has "long" and "unsigned long" as 32-bits, and "size_t" as 64-bits. So, it would seem that code that called AES_ctr128_encrypt() compiled under 0.9.8o would push 32-bits less 
onto the stack on AMD/Itanium than code using the 1.0.0a headers.
Just about every other popular compiler model I can think of, primarily W32, 
Unix 32, and Unix 64 LP64 would not experience a problem.
If I'm correct, code calling these functions on AMD/x64 would need maybe two different function pointers defined for AES_ctr128_encrypt(), and on the fly switching between the two, depending on the version retrieved from LIBEAY32.DLL. 
Am I missing something here?
Thanks in advance for your help,
JGS



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager [email protected] 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to