I seem to have 1.0.0d builds working on VMS with 32- or 64-bit
pointers, but I'm still waiting for some guidance on how to make some of
the needed changes:
1. I need a macro/typedef for an integer with the same size as a
pointer. On non-VMS systems "intptr_t" might be suitable, but not on
VMS, so it appears to me that some new OpenSSL-specific thing must be
added. I can get it defined appropriately on VMS. Elsewhere, I don't
care; "size_t" (as is used now), "intptr_t", whatever. But I'd be
happier (others, too, I'd guess) if someone else chose the name,
placement, and other details.
I've identified two places where use of "size_t" caused problems on
VMS with 64-bit pointers, "crypto/bn/bn_mont.c" and
"crypto/bn/bn_nist.c". It might be wise to scan the code for other
inappropriate uses of "size_t", as I haven't done that.
2. The argv-using "apps/*.c" programs need reform to use "argc"
instead of looking for a NULL terminator at the end of "argv[]".
(Looking for a NULL makes sense for "envp[]", which is expected to be
NULL-terminated, but not so much for "argv[]", where it causes bad
behavior on VMS Alpha with 64-bit pointers, and where "argc" is
obviously available and suitable.) I've converted "apps/cms.c" and
"apps/smime.c", because those were causing test failures. My current
scheme changes code like this:
[...]
int MAIN(int argc, char **argv)
[...]
char **args;
[...]
args = argv + 1;
[...]
while (*args) [or similar]
[...]
args++;
[...]
to code like this:
[...]
int MAIN(int argc, char **argv)
[...]
int argi;
char **args;
[...]
argi = 1;
args = &argv[argi])[0];
[...]
while (argi < argc) [or similar]
[...]
args = &argv[++argi];
[...]
The maintainer(s) may prefer some other scheme/details, so I'm reluctant
to fiddle with the other, similar programs in that collection until
someone higher up nods, or complains, or something. (Also, I wouldn't
bet that any other of those programs gets tested on VMS, so there's
probably some risk in my making the changes to them.) For the ones I
have changed, I can supply patches or whole replacement files, if anyone
is interested.
If some decision maker can settle these pending items, then I can
pack this batch of changes into a form which might be more easily
adopted into the main code base.
Other changes:
I've added a C macro, OPENSSL_NO_SETVBUF_IONBF, which is defined only
on VMS, and which is used to bracket instances of "setvbuf(..., _IONBF,
...)". On VMS, this use of setvbuf() is unsupported, and is
incompatible with 64-bit pointers. Everyone else can ignore this new
macro, and get the same behavior as before.
I've modified the VMS builders to allow the user to specify a path to
a zlib object library (expecting "zlib.h" to be in the same directory).
I've also done some tidying in the VMS builders (typography, lame
code reduction, ...).
I've added a new VMS-specific header file, "crypto/vms_rms.h" to
reduce the code clutter involved with NAM versus NAML (RMS file name)
structures (in "crypto/LPdir_vms.c" and "crypto/dso/dso_vms.c"). I use
essentially similar stuff in many other projects. You're welcome to it.
(I haven't added a copyright heading.)
------------------------------------------------------------------------
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
