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

[David Froble]

Craig A. Berry wrote:
> On 1/6/16 8:08 AM, John Reagan wrote:
>> 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?
> 
> Well, lib$routines.h and starlet.h already have defines that do, for
> example:
> 
> #define  sys$qio  SYS$QIO
> 
> which, for interfaces where the owner is willing to say that the upper
> case and lower case versions are really the same thing and is willing to
> maintain the macros, is a good enough solution. It doesn't really help
> you when you don't own the interface.
> 
>> 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').
> 
> Yes, that is the real reason for it, and while you may be right that
> there aren't very many projects that really require it, one library in
> your dependency chain that does need it means you need it for everything
> in your dependency chain.
> 
>> 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?
> 
> The thing is, we're in an "encrypt everything" world, and the place most
> folks go for that is some version of libcrypto, which is a dependency
> for a ton of other libraries and projects, curl being one of them. If
> you are building one of those packages and it requires you to build with
> AS_IS, then you need your libcrypto to provide compatible symbols, one
> way or another.
> 
> Side note: if anyone is concerned about keeping track of both upper and
> lower case versions of a symbol that also needs to be shortened, please
> note that you cannot just shorten the mixed-case version and then upper
> case the result. You must shorten the mixed-case version, then upper
> case the full symbol and shorten that as well. I haven't looked to see
> whether shimmer handles this but I'm pretty sure the suggestion of
> imgexp + bash doesn't.
> 

Following this with interest, ....  and disgust ....

As far as encryption goes, I seem to recall reading somewhere that Microsoft 
gave up on OpenSSL and developed their own software.  Could be wrong about this.

However, if it's so, and I do believe weendoze is not case sensitive, would not 
looking at their software as a solution for encryption on VMS be a valid solution?

No idea if it might be available ..

I'm guessing that the MS product works with systems using OpenSSL, so there 
should not be a problem there.  I'm also guessing that the routines, symbols, 
whatever, may or may not be the same names in OpenSSL, and might not be a 
solution for*ix code ported to VMS.

Don't know if this idea has any value, (Brian is probably throwing things 
against a wall), but it doesn't hurt (too much) to throw it out there for 
someone more knowledgeable to stick voodoo pins into it ...