From: Richard Levitte <rich...@levitte.org>
To: openssl-dev@openssl.org, sms@antinode-info
R:
I'm subscribed to the list, so the extra copy isn't needed.
> about your latest changes, it seems that it has SSL_LIBCRYPTO32.OLB
> and SSL_LIBSSL32.OLB as default names (when have specified "" for the
> bits parameter)... is that your intention? I find it a bit
> confusing, I'd rather expect something like this:
>
> bits="" => SSL_LIBCRYPTO.OLB, SSL_LIBSSL.OLB
> bits="32" => SSL_LIBCRYPTO32.OLB, SSL_LIBSSL32.OLB
> bits="64" => SSL_LIBCRYPTO64.OLB, SSL_LIBSSL64.OLB
So far as I know, there is no difference between the results you get
from specifying "" and those you get from specifying "32", so I didn't
try to name then differently. I believe that the default,
/NOPOINTER_SIZE, and an explict /POINTER_SIZE=32 differ only in that
/POINTER_SIZE=32 enables the use of features like "#pragma
pointer_size", and we use these (even indirectly) only in the
64-bit-pointer case. On my VAX (V7.3) system, where there is no
/[NO]POINTER_SIZE option, HP uses the "32" names for the shared images:
Directory SYS$COMMON:[SYSLIB]
SSL$LIBCRYPTO_SHR32.EXE;1
1653 1-APR-2004 11:05:45.08 (RWED,RWED,RE,RE)
SSL$LIBSSL_SHR32.EXE;1
381 1-APR-2004 11:06:00.95 (RWED,RWED,RE,RE)
On my non-VAX systems (Alpha V8.3 shown here), I see:
Directory SYS$COMMON:[SYSLIB]
SSL$LIBCRYPTO_SHR.EXE;1
3139 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE)
SSL$LIBCRYPTO_SHR32.EXE;1
3055 9-JUN-2006 09:49:58.37 (RWED,RWED,RE,RE)
SSL$LIBSSL_SHR.EXE;1
492 9-JUN-2006 09:49:15.55 (RWED,RWED,RE,RE)
SSL$LIBSSL_SHR32.EXE;1
483 9-JUN-2006 09:49:58.82 (RWED,RWED,RE,RE)
So, my plan was to follow this scheme, and have a "32" at the end of all
the 32-bit-pointer (.EXE and .OLB) names, and nothing in the
64-bit-pointer names. But I'm open to a good argument for any other
reasonable scheme. (At least, with the "SSL_" prefixes, we can
distinguish the new (no "32") 64-bit stuff from the old (no "32") 32-bit
stuff. Everything's complicated.)
> Also, it seems that /POINTER_SIZE=64=ARGV isn't supported with HP C
> 7.1. I get this when trying to build the test programs with your
> latest scripts, once for each file:
>
> %DCL-W-NOVALU, value not allowed - remove value specification
> \64=\
>
> And indeed, I can't find that in the help file either...
>
> $ cc/ver
> HP C V7.1-015 on OpenVMS Alpha V8.3
That's depressing. My first impulse is to say that 64-bit pointers
require a newer compiler. It's possible that the "=ARGV" isn't really
needed, but I thought that that was the cure for the "ACCVIO" in the
subject line of this thread. I'll go back and check, but I believe that
without the "=ARGV", the libraries and shared images may be ok, but all
the main programs (openssl itself, and some/all of the tests?) will
explode when they start passing 32-bit argv[] pointers around to
consumers who expect 64-bit pointers. (HP supplies only one
OPENSSL.EXE, and I'd bet that it's a 32-bit-pointer edition.)
If the "=ARGV" really is needed to make the main programs work, then
we can either require a newer compiler, or, perhaps, do more/different
argv[] copying (on VMS) to provide a 64-bit argv[] when the C
environment won't. (Which doesn't sound to me like much fun.)
On a related topic, for those who haven't followed it, the ITRC
discussion of the bad-argv[]-termination problem seems to have come to
rest:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1472203
The conclusion seems to be that the problem originally affected both
Alpha and IA64, and that there was an ECO to fix the problem on IA64
(June 2010, which I seem to have installed on my IA64 systems), but none
(yet) for Alpha. (Not enough complaints from paying Alpha customers, I
assume.) The existing work-around in "apps/openssl.c" is conditional
only on OPENSSL_SYS_VMS, so we should be safe everywhere. (And it
wastes only a very little time when it's not needed.)
SMS.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
