I have not been able to work with the code since December 2023, when I came down with Long Covid, except for fixing a few minor compilation warnings. Any time I try to do anything more ambitious, I become hopelessly confused. I have no idea when or if the brain fog will clear.

Before the final release of C-Kermit 10, I'll need volunteers to address the pending portability and compliance issues, most of them due to Clang, and to change the OpenSSL support to work with both old (V1) and new (V3) of OpenSSL (which was beyond me even when I wasn't sick).

To paraphrase Edsgar W Dijkstra, "Clang considered harmful". Each new Clang release spews out more warnings about perfectly legal C code, each of which threatens to become fatal in future Clang releases at the whim of some unaccountable person(s), thus killing off countless thousands or millions of C programs written in compliance with the original language definition over the past 50+ years. For example see the Clang 18.1.8 builds below, compared with earlier Clang versions. Remember: the whole purpose of the C language is to be PORTABLE.  For greater detail CLICK HERE.

Beta-11 builds (so far) by Michael Bernardi (West Sussex, England), Peter Eichhorn (Assyst GmbH, Aschheim-Dornach, Germany), Alexander Kochetkov (Александр Кочетков, Moscow), Tony Nicholson, Steven M. Schweda, and me (Bronx NY).

June 2024 Builds (changes for VMS only)...

More suggested changes for x-20240426 follow, generally related to different hardware architectures on VMS, but perhaps not entirely?

      ckcdeb.h
      ckclib.c:ckround()

#ifdef __alpha

Why only __alpha? What about other 64-bit systems? As usual, on VMS the relevant condition is VAX v. non-VAX, not __alpha or __ia64 or __x86_64 (or whatever might come next).

I've created a new macro, FLT_NOT_DBL, in ckcdeb.h, for use in ckclib.c:ckround(), getting __alpha out of ckclib.c. FLT_NOT_DBL is (now) defined on all 64-bit VMS hardware.

Off VMS, it's still defined if __alpha is, so non-VMS code that relied on __alpha should not be affected. (Tru64? GNU/Linux?) Whether that ever made any sense, I couldn't say. As always, I claim that any such hardware dependencies should be confined to ckcdeb.h, and a generally feature-descriptive macro should be used elsewhere in the code. (Unless you actually want to identify the hardware.)

      ckcdeb.h
      ckuus5.c:prtopt()
      ckvtio.c:gftimer()

From ckvtio.c:gftimer():

> /* 2024-05-16 SMS.  Original code using sys$gettim() used
>  * lib$cvtf_from_internal_time() to get to floating-point (FP), which
>  * produced VAX FP values.  This failed when IEEE FP was used, which
>  * became the default beginning with IA64 hardware.  Old/unnatural
>  * work-around:
>  *
>  *    #ifdef VMSI64
>  */   /*  The native VMS code is broken in VMS/IA64 8.1. */   /*
>  */   /* Luckily, in VMS 8.1 we can use the Unix code. */     /*
>  *
>  * This condition fails on x86_64, or with CC/FLOAT=IEEE_FLOAT (on
>  * Alpha, for example), because the condition of interest is the FP
>  * style in use, not the hardware architecture.
>  *
>  * Modified code uses sys$gettim() everyplace, and tests the FP style,
>  * not the hardware architecture (using lib$cvts_from_internal_time()
>  * for IEEE FP).  Define GFTIMER_UNIX to get the (still available)
>  * alternate (gettimeofday(), et al.) scheme.
>  */

I also changed the variable name "s" to "fp_time", so that I could find it using a text editor.

This removes the only (poor) reason for the macro VMSI64, so I removed it from ckcdeb.h and the reported options in ckuus5.c:prtopt().

ckcdeb.h:
ckcfns.c:
ckufio.c:
ckuus4.c:

Changed MAXNAMLEN to CKMAXNAM. Link problems on VMS (and, perhaps, other non-UNIX systems) were caused by global variables (maxnam, maxpath) not declared on all systems, and/or macros (MAXNAMLEN, MAXPATHLEN) not defined on all systems. A new macro, CKMAXNAM, is now defined in ckcdeb.h.