[Info-vax] Once again trying to use the SSL ported to VMS

[Bob Koehler]

In article <a31762a8-058e-4adf-85f7-bb46a82721df at j10g2000vbe.googlegroups.com>, David Froble <davefroble at gmail.com> writes:
> My problem with this is, I'm not sure what C considers (a) NULL.  If I
> can test the variable/pointer/whatever for a value of zero, that's
> simple, but there is nothing I can find that tells me a test for zero
> would be appropriate, thus my "assume".

   Although the macro NULL is almost always defined in a C header
   somewhere, language experts state that it must be 0.  So a
   comparison of a pointer to 0 in code is always interpreted as
   "compare this pointer to whatever the null pointer actually is
   on this system".  In practice, even computers which have a
   valid address at 0 will use 0 as the "this pointer is null"
   value.

> 
> SSL_CTX_new() does seem to allocate some storage, and the return value
> I'm assuming is a pointer to the storage.  It is non-zero, so I've
> assumed it was successful.  Doesn't make sense to return a pointer to
> storage that was never allocated.

   Good enough.

> 
>>    Have you tried looking at what passes for documentation at
>> openssl.org?
> 
> No I have not, and from the way you phrased that, I'm probably going
> to be disappointed.  We'll see.
> 
>> > I assume decc$socket_fd() is a DEC C routine,
>>
>>    Why assume anything?  Around here:
>>
>>       help TCPIP_Services Programming_Interfaces Socket_API_Functions
>> -
>>        decc$socket_fd
> 
> Yes, I had found that, but if you read it, you'll see that while it
> says that a small integer value is returned, I'm not sure what that
> means.  Does it mean a byte, a word, or just a low value.  Since it's
> returning a value, I'm assuming that I can store it in a longword.

   The documentation says:

      int decc$socket_fd (int channel);

   And I'm fairly sure that more than one document says DEC C "int" is
   32 bit.