From: "Green, Paul" <paul.gr...@stratus.com> > > What seems (to me) to be needed in these cases is some macro or > > typedef which is an integer whose size is reliably the same as > > that of a pointer, which size_t is not. =20 > > Hi Steve, Please take a look at your copy of stdint.h. See if you have > a definition for the "intptr_t" and "uintptr_t" types.
Around here, they're in <inttypes.h>. (We don't have to show you any stinking <stdint.h>!) > The POSIX standard(*) says "The following type designates a signed > integer type with the property that any valid pointer to void can be > converted to this type, then converted back to a pointer to void, and > the result will compare equal to the original pointer: intptr_t." Ditto > for uintptr_t, except that it is unsigned. > > The standard also says that intptr_t and uintptr_t are required on > XSI-conformant systems; otherwise, they are optional. So you might have > to define _XSI_SOURCE to make their declarations visible. > > It seems to me that this data type is just what you (and OpenSSL) are > looking for. Hope this info helps. You might think so, but, in its boundless wisdom, DEC/Compaq/HP has implemented these things in an unfortunate way: /* ** Declare [un]signed integral types large enough to hold any pointer. */ #if !defined(__VAX) typedef int64_t intptr_t; typedef uint64_t uintptr_t; #else typedef int32_t intptr_t; typedef uint32_t uintptr_t; #endif So, on a non-VAX (64-bit-capable) system, these types are _always_ 64 bits, irregardful of the actual pointer size. This leads to annoying complaints like %CC-I-INTCONSTTRUNC (and friends) when trying to get from one of these types back to a 32-bit pointer. I sent a complaint about this to HP back in 2009, but the responding Indian didn't see it as a problem, so I gave up. (And even if they did fix it now, many old systems would be stuck with the problem, so it's mostly hopeless.) Because of these sorry facts, I see no easy way to avoid adding and using an OpenSSL-defined type, although on most systems, "intptr_t" would seem to be an ideal value to use for the thing. > (*) The POSIX-2008 standard is online at > http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm. You must > pre-register to view it, but the registration step carries no charge and > is simple to perform. Thanks for the link. Perhaps I'll forward that to HP when I get sufficiently bored. On a different point, a closer look at the 64-bit-pointer test results shows a problem on Alpha (but not on IA64) somewhere in the "CMS => PKCS#7 compatibility test" sequence. Perhaps some file I/O thing? The perl script doesn't seem to handle an explosion here very well. A search for "fail" in the test results transcript won't detect the absence of an "ALL TESTS SUCCESSFUL" message, making it easy for a casual inspection to miss this kind of failure. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
