I don't think everything has to be size_t-fied. In some situations it
Do you care about 16bit platforms?
Well, I was wondering this question myself. Do we? Does *anybody* compile OpenSSL on 16-bit platforms nowadays? Is it still of interest? What 16-bit platforms are out there? But in either case...
Perhaps use "sslsize_t" (or sizeu32_t) which is usually size_t, but not necessarily so.
As for using sizeu32_t in place for size_t on 16-bit platform such as MS-DOS or Win16. Would it actually work? What is size_t? It's an integer type to be used in "native" pointer arithmetics. Would an attempt to use 32-bit value in pointer arithmetic on 16-bit platform be successful? As far as I remember even in huge model pointer arithmetics for basic types such as char is still limited to 16 bit(*). But if there are compilers which overcome this limitation, shouldn't they define size_t as 32 bit rather than implying that programmers would come up with kludges? A.
(*) Indeed, here is the loop body from "foo (int *p,long l) {while(l--)p[l]=0;}" compiled with TurboC 2.01 in huge model:
@4:
mov ax,word ptr [bp+10]
shl ax,1
les bx,dword ptr [bp+6]
add bx,ax
mov word ptr es:[bx],0
@2:
mov dx,word ptr [bp+12]
mov ax,word ptr [bp+10]
sub word ptr [bp+10],1
sbb word ptr [bp+12],0
or dx,ax
jne @4Note that only least significant part of l is used in pointer arithmetics. So that if you're concerned that SHA1_Update would all of a sudden become impared on MS-DOS, then there is no reason worry: it hardly ever worked:-)
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
