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
