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

[Steven Schweda]

On Nov 28, 2:00 pm, David Froble <davefro... at gmail.com> wrote:

> It's my observation that the OpenSSL port to VMS is actually a port to
> C on VMS.  [...]

   OpenSSL is software written (mostly) in C, so that's what
you get when it's ported to VMS.

   I've done very little with OpenSSL, other than try to get
the VMS builders to work, and then use the results with other
programs (already) written in C (by others), so I know
nothing, but, ...

> [...] Not ranting, just explaining.

   Had me fooled.

> [...] I could
> not find much about what "RETURN_NULL()" is, though I can guess it is
> initializing a new structure to NULL.  The symbol does not resolve in
> the linker.  The only place I've found it is in another example
> program.
>
> #define RETURN_NULL(x) if ((x)==NULL) exit(1)

   Around here, it's defined in SSL_EXAMPLES.H, which seems
to be used by SSL$TCP_SERVER_QIO_SSL.C:

ALP $ search SSL$TCP_SERVER_QIO_SSL.C SSL_EXAMPLES.H
 *             See SSL_EXAMPLES.H for more information and further
debug
#include "SSL$EXAMPLES:ssl_examples.h" /* SSL callbacks and error
handling  */

So, not particularly mysterious.  It doesn't initialize
anything.  It checks its argument, and if it's NULL, then it
calls exit() (with a non-zero/error code).  For example:

   /* Create a SSL_CTX structure */
   ctx = SSL_CTX_new(meth);
   RETURN_NULL(ctx);

Apparently, SSL_CTX_new() allocates some storage, and returns
a pointer to that storage.  If it returns NULL, then you're
doomed (probably because the allocation failed), so exit(1)
probably makes some sense.

   Have you tried looking at what passes for documentation at
openssl.org?

> 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

>  and I assume that the
> channel is being passed to it By Value.

   Again, what's to assume?  If you can't read C, then this
may be a tough nut to crack.

>   I don't know what it's doing,
> and I don't know what type of data it returns.  I can "hope" that
> "sock" is a pointer, to be stored in a longword.

      help TCPIP_Services Programming_Interfaces Socket_API_Functions
-
       decc$socket_fd

> Back to ranting.  [...]

   I thought so.

   The documentation of this stuff may be sub-ideal, but you
don't seem to be taking proper advantage of what is
available.