[Info-vax] cURL/libcurl 7.46 PCSI kits available.

[Stephen Hoffman]

On 2016-01-06 14:08:14 +0000, John Reagan said:

> On Tuesday, January 5, 2016 at 6:26:27 PM UTC-5, Stephen Hoffman wrote:
> 
>> 
>> But since I was apparently unclear, allow me to clarify:   The SSL and> 
>> SSL1 kits are broken.  They don't properly deal with mixed-case.
>> 
> 
> No worse than a call to a lib$ routine when compiled with /NAMES=AS_IS. 
>  The link will fail.  So is LIBRTL.EXE broken?  The rest of the RTLs?  
> The public vector?  Want SYS$QIOW and sys$qiow?
> 
> There is no wide-spread use of lowercase names in symbol vectors.  
> Using AS_IS is just asking for trouble unless you can compile the whole 
> environment that way.  The CRTL provides both to help so-called 
> portable C99 programs to come to OpenVMS.  However, in my opinion (and 
> in reading the C notefile going back decades), AS_IS really was there 
> to help programs that did such things like call both 'getenv' from the 
> CRTL and 'GetEnv' from their own code (perhaps as a wrapper over 
> 'getenv').  The C99 standard prescribes case-sensitive external names 
> and AS_IS is there to meet that requirement.
> 
> So are SSL and SSL1 to be considered part of some of 'virtual' CRTL 
> such that you need lower-case name support?  How about the next set of 
> images or the next?


I am well aware of the problems with /NAMES=AS_IS, and there are 
situations where that's necessary.  I've hit those and expect to be 
hitting more of those cases, and the reason Shimmer was written was 
some other open source that had the same issues.  More than a few folks 
porting code to VMS have hit these cases, too.   For the creation of 
Shimmer, the SSL bits were the part of the whole environment that 
wasn't properly case sensitive.  Hence here we are.

One of the admittedly obscure packages involved here was cURL.   (IIRC, 
libxml2 is another obscure case, but that's from dim recollection of a 
port from several years ago.)

For those following along at home, the SSL programming interfaces are 
accessible from C, C++, Macro32, Bliss32, Bliss64, and such.   From 
other descriptor-based languages, there are the usual hassles with 
calling C APIs — the null-terminated strings and APIs that use pointers 
usually require some extra work in the calling code, at the APIs.  (Or 
jackets — see below.)

This case is much closer to that with X Windows and the parallel APIs — 
what DECwindows provided both the MIT C bindings and the VAX bindings — 
then to anything involving LIBRTL.  I don't expect portable C or C++ 
code to be using LIBRTL calls, either.   For better or worse, I do 
expect portable C or C++ code to potentially be case-sensitive, and to 
be using X or SSL calls.  (I have this vague recollection that libxml2 
had an example or two of this case-sensitivity, for instance.)

Pulling back somewhat from the immediate problem, OpenVMS needs its own 
set of security bindings — this for various reasons, not the least of 
which is to better isolate the SSL APIs from the OpenVMS-native 
callers, to simplify the TLS and certificate and related interfaces in 
general, to add support for descriptor-based languages, and to 
integrate with whatever certificate- and password-storage system VSI 
might eventually decide to consolidate toward.   This in addition to 
the existing portable bindings.

While this is getting nuked and paved, the Rdb approach for selecting 
parallel RTLs to allow easier migrations forward is vastly easier than 
the almost-distinct parallel SSL$ and SSL1$ approach, too.

Either OpenVMS adapts to the world, or the rest of the world... doesn't bother.

But in general, getting SSIO and some API jackets solved are bigger and 
more interesting giblets here, as there's a workaround for this 
particular problem.


OpenSSL jackets for OpenVMS:
http://labs.hoffmanlabs.com/node/1853

Shimmer:
http://labs.hoffmanlabs.com/node/1906




-- 
Pure Personal Opinion | HoffmanLabs LLC