Re: New VSI blog post

On 7/30/2024 6:21 PM, Richard Jordan wrote:

On 7/29/24 6:44 PM, Arne Vajhøj wrote:

For those that have not seen it:
>
https://vmssoftware.com/resources/blog/2024-07-26-rtl8/
>
(Darya is listed as author, John Reagan is quoted in it)
>
Content is a rather unusual mix of:
* some business/admin stuff
     - 8.4-2L1 going out of standard support in December
       so time to update to 8.4-2L3
     - a warning about known issues in C RTL 8 and a suggestion
       to wait for C RTL 9
* some programming notes about problems related to:
     - use of uninitialized variables
     - mismatch between 32 and 64 bit

Just to request clarification... are the C RTL issues across all platforms or just x86 specific?  The blog post mentioned the legacy GEM compiler "would" (past tense) pad the space and the LLVM does not.

It is non x86-64 specific.
I think it was first reported on Alpha:
https://forum.vmssoftware.com/viewtopic.php?f=1&t=9138
Where a VSI'er stated:
<quote>
Inside DECWindows there is a mix of calls to malloc/free/realloc and lib$vm_malloc/lib$vm_free/lib$vm_realloc. For example, decc$malloc is called, and then the resulting pointer is passed to the lib$vm_realloc function. Formally this is mistakes, but before CRTL-V8.0 it was allowed. But in V8.0, the function posix_memalign was added, it required adding some additional information to the internal structures associated with memory allocation. And the functions free and lib$vm_free became incompatible.
I've fixed it. But the fix will probably be available in V9.0
</quote>
which matches the text from the blog:
<quote>
Mark Stiles, the L3 engineer working with RTL patch kits, explains, "There is a modification in the RTL V8 kit which introduced a problem for legacy code. It is responsible for the DECwindows startup problem below and may be (and likely is) the cause of the access violations mentioned below. In brief, a change to tighten up POSIX-compliant routines in memory allocation use had unintended side effects when both POSIX and non-POSIX methods of application virtual memory access were used simultaneously, and may have bled into even just non-POSIX aware code. We are fairly certain we have the fix for this and intend to release it along with other changes in an RTL V9 kit (we know that it fixes the DECwindows startup problem). We have recommended customers who experience issues with the RTL V8 kit remain on the prior RTL V6 kit until the V9 kit is available.
</quote>
So not LLVM related, but C RTL Posix-compliance related.

We're not getting LLVM behavior on the older systems, are we?  Alpha and Integrity behavior will remain the same?

I have not heard anything about VSI wanting to use LLVM backend on
Alpha or Itanium.

I ask because we no longer have access to a C compiler; connecting code was built to interface BASIC to FreeTDS, GSOAP and other packages long ago when we had the HP developer licenses which are long gone.  I only have access to BASIC (which is the primary language) and really don't want to try to rewrite the connector code if it turns out to have problems on an upgraded test system.

If you have any doubt then skip C RTL 8 and wait for 9.
It does not matter whether the C compiler is present or not.

And also don't want to find out we have issues with any packages that VSI may no longer be supporting (like GSOAP?)

VSI apparently has GSOAP for Alpha, Itanium and x86-64:
https://vmssoftware.com/products/gsoap/
Arne