[Info-vax] New VSI blog post

[Arne Vajhøj]

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