OS/2 is another possibility, that also supported 16 and 32 bit code.
Our team's port is 32 bit , but I can't be sure everyone using OS/2 will be using 32 bit code.
Relevant question [in the context of this discussion] is if there is a 16-bit compiler environment, which would provide for pointer arithmetics wider than 16-bit [per array of elements of basic type]. If there is, then the next question is if there is a 16-bit OpenSSL application out there, which is
- compiled in such environment;
- actively maintained;
- may not be executed on 32-bit capable hardware or can't be ported to a 32-bit environment (e.g. DJGPP);
Hardly. But if there is, then they just have to adapt it for updated size_t-fied API, e.g. slice 96KB message to be hashed into 64 and 32KB chunks and make two calls instead of one. Why? Because it actually makes their program compliant with common language standard and therefire more portable:-) That shouldn't be a problem if application is actively maitained, should it? It it's not actively maintained, then it just run out there, likned with elder OpenSSL version, which is not going to be size_t-fied and there is no problem.
In other words I still don't see that size_t-fication of OpenSSL API indicates that that we care less about 16-bit platforms. A.
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
