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

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/29/2024 7: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

Arne

Yeah, we've been trying to balance changes to the CRTL that:

1) Increases our POSIX and open-source compatibility

2) Doesn't break legacy code that relies on existing behavior

3) Doesn't add any new CRTL feature logicals

We are planning additional CRTL work that will enable using
clang in "C-mode" to get C11 (and perhaps some of C18) support. Also,
newer C++ standards support in LIBCXX expects some of those C11 features
as well. The dependencies can be twisty.

And in lieu of an actual porting guide, I've been asked about "what
things are catching people porting code from Itanium to x86". Other
than bugs in the compilers and OS, the most common issue I've seen is a mismatch of 32/64 bit variables. I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable. On Alpha and
Itanium, GEM would allocate 32-bit variables into their own quadword on
the stack. Back in the old Alpha days, quadword granularity was very important. It became less important on later Alphas and Itanium but
still had limited benefit. For x86, there is no reason for it and LLVM
will just allocate 32-bit variables on the stack right next to each
other. The overwrite on Alpha/Itanium would just touch that extra
alignment hole. On x86, the overwrite clobbers the adjacent variable.
It mostly has been in BLISS and C code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-29, John Reagan <johnrreagan@earthlink.net> wrote:

Other
than bugs in the compilers and OS, the most common issue I've seen is a mismatch of 32/64 bit variables. I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable.

[snip]

It mostly has been in BLISS and C code.

I don't know enough about BLISS to make a judgement about how bad the
code that does this is, but I would be very interested to see the C code
that makes this possible.

Without an obviously incorrect explicit type conversion (which is a serious
bug in the user's C code), I am not seeing how this is possible under C
as the compiler should generate the appropriate size-conversion code automatically if you assign from a 64-bit variable into a 32-bit variable.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-30 03:28:16 +0000, John Reagan said:

And in lieu of an actual porting guide, I've been asked about "what
things are catching people porting code from Itanium to x86". Other
than bugs in the compilers and OS, the most common issue I've seen is a mismatch of 32/64 bit variables. I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable. On Alpha and
Itanium, GEM would allocate 32-bit variables into their own quadword on
the stack. Back in the old Alpha days, quadword granularity was very important. It became less important on later Alphas and Itanium but
still had limited benefit. For x86, there is no reason for it and LLVM
will just allocate 32-bit variables on the stack right next to each
other. The overwrite on Alpha/Itanium would just touch that extra
alignment hole. On x86, the overwrite clobbers the adjacent variable.
It mostly has been in BLISS and C code.

?

BLISS has ample opportunities for foot-guns, but C usually flags
integer or float mismatches that would lead to overflows or
truncations. Which leaves buffers and strings.

I've certainly clobbered storage loading ten kilograms of data into a
five kilogram malloc, among other sorts memory management "fun".

Given compiler errors are called out separately, and given examples of
errors aren't offered, and given as few as roughly twenty cases found
across ~everything, this seems like device drivers or kernel
shenanigans with builtins or asm or such, or incorrect casting, or
errant memcpy or lib$movc calls or ilk, or a strcpy that null
terminates a four-byte transfer into the fifth byte, or maybe just
buggy C code built with compiler diagnostics detuned or disabled. I'm
guessing the errors specific to the sorts of things some hunk of
OpenVMS C or BLISS is usually doing. Maybe a wrong size constant
somewhere? Or a strcpy into a longword that spills the null?

What amounts to tearing when adjacent variables were within the same granularity was a wonderfully subtle and gnarly mess with asynchronous
code aeons ago. But that doesn't fit the description here.

Given few cases and no examples, I'm assuming it's just some
brain-cramp or another, and not a generic issue. Ports do traditionally
tend to expose packing and padding issues, too.


--
Pure Personal Opinion | HoffmanLabs LLC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/24 5: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

Arne

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.

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

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.

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

As far as I can see, there is no "RTL v8" kit for x86, only Alpha and
Itanium. So I infer the RTL v8 kit is a bridge to get the CRTL (and
maybe other RTLs) on Alpha and Itanium up to where it is on OpenVMS x86
9.2-2. If there is an RTL kit for x86 before 9.2-3, I don't think it
would be "v8." But this is just me making inferences based on how I
think it works.

On your C compiler problem, have you priced a single-user license on one
node just to be able to build stuff?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Arne

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.

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

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.

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

Thanks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/2024 6:46 PM, Craig A. Berry wrote:

As far as I can see, there is no "RTL v8" kit for x86, only Alpha and Itanium. So I infer the RTL v8 kit is a bridge to get the CRTL (and
maybe other RTLs) on Alpha and Itanium up to where it is on OpenVMS x86 9.2-2.  If there is an RTL kit for x86 before 9.2-3, I don't think it
would be "v8."  But this is just me making inferences based on how I
think it works.

I checked - the 8 kit is only available for:
Alpha 8.4-2L1 and 8.4-2L2
Itanium 8.4-2L1 and 8.4-2L3

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/2024 8:25 AM, Simon Clubley wrote:

On 2024-07-29, John Reagan <johnrreagan@earthlink.net> wrote:

Other
than bugs in the compilers and OS, the most common issue I've seen is a
mismatch of 32/64 bit variables. I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable.

[snip]

It mostly has been in BLISS and C code.

I don't know enough about BLISS to make a judgement about how bad the
code that does this is,

I don't think Bliss is the right language for 100% type safe code.

:-)

but I would be very interested to see the C code
that makes this possible.

Without an obviously incorrect explicit type conversion (which is a serious bug in the user's C code), I am not seeing how this is possible under C
as the compiler should generate the appropriate size-conversion code automatically if you assign from a 64-bit variable into a 32-bit variable.

I have no idea what examples John is seeing, but it is not that
hard to come up with examples.

Ignoring warnings:

$ type warns.h
#include <stdint.h>

void something(int64_t *v);
$ type warns.c
#include <stdint.h>

#include "warns.h"

void something(int64_t *v)
{
*v = -1;
}

$ type warnm.c
#include <stdio.h>
#include <stdint.h>

#include "warns.h"

int main()
{
int32_t v[3] = { 0, 0, 0 };
something(&v[1]);
printf("%ld %ld %ld\n", v[0], v[1], v[2]);
return 0;
}

$ cc warns
$ cc warnm

something(&v[1]);
..............^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer
value "&v[1]" is "int", which is not compatible with "long
long".
at line number 9 in file DKA0:[arne.bits]warnm.c;1
$ link/exe=warn warnm + warns
%ILINK-W-COMPWARN, compilation warnings
module: WARNM
file: DKA0:[arne.bits]warnm.OBJ;2
$ run warn
0 -1 -1

Having an inconsistent declaration and forget to
include .h in implementing .c file:

$ type nowarns.h
#include <stdint.h>

void something(int32_t *v);
$ type nowarns.c
#include <stdint.h>

//#include "nowarns.h"

void something(int64_t *v)
{
*v = -1;
}

$ type nowarnm.c
#include <stdio.h>
#include <stdint.h>

#include "nowarns.h"

int main()
{
int32_t v[3] = { 0, 0, 0 };
something(&v[1]);
printf("%ld %ld %ld\n", v[0], v[1], v[2]);
return 0;
}

$ cc nowarns
$ cc nowarnm
$ link/exe=nowarn nowarnm + nowarns
$ run nowarn
0 -1 -1

Having an inconsistency and use old style function
declaration without arguments:

$ type badolds.h
void something();
$ type badolds.c
#include <stdint.h>

#include "badolds.h"

void something(int64_t *v)
{
*v = -1;
}

$ type badoldm.c
#include <stdio.h>
#include <stdint.h>

#include "badolds.h"

int main()
{
int32_t v[3] = { 0, 0, 0 };
something(&v[1]);
printf("%ld %ld %ld\n", v[0], v[1], v[2]);
return 0;
}

$ cc badolds
$ cc badoldm
$ link/exe=badold badoldm + badolds
$ run badold
0 -1 -1

Mixing VMS C and Clang C without consideration:

$ type trickys.h
void something(long *v);
$ type trickys.c
#include "trickys.h"

void something(long *v)
{
*v = -1;
}

$ type trickym.c
#include <stdio.h>

#include "trickys.h"

int main()
{
long v[3] = { 0, 0, 0 };
something(&v[1]);
printf("%ld %ld %ld\n", v[0], v[1], v[2]);
return 0;
}
$ clang trickys.c
$ cc/name=as_is trickym
$ link/exe=tricky trickym + trickys
$ run tricky
0 -1 -1

All of the above is bad in some ways.

Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.

But bad things has been seen out in the big world.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 31/07/2024 21:50, John Reagan wrote:

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

Arne

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.

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

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.

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

Thanks

Most of our CRTL changes have been for all targets.  For Alpha/Itanium,
the delivery method is with ECO kits.  For x86, simplying upgrading the
OS from V9.2 to V9.2-1 to V9.2-2 etc. will pick up the new features.

The LLVM code generator is only for x86 targets.  There are no currently active LLVM targets for Alpha or Itanium.  There would be no benefit to
a switch, only lots of risk.  We haven't upgraded the Alpha/Itanium compilers in a long time.  The only one with an active bug we need to
fix is with the /SEPARATE qualifier with Fortran and BASIC on Itanium
(it is also broken for a different reason on x86)

The x86 BASIC compiler is finished and will be available on the portal
in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Arne

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.

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

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.

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

Thanks

Most of our CRTL changes have been for all targets. For Alpha/Itanium,
the delivery method is with ECO kits. For x86, simplying upgrading the
OS from V9.2 to V9.2-1 to V9.2-2 etc. will pick up the new features.

The LLVM code generator is only for x86 targets. There are no currently
active LLVM targets for Alpha or Itanium. There would be no benefit to
a switch, only lots of risk. We haven't upgraded the Alpha/Itanium
compilers in a long time. The only one with an active bug we need to
fix is with the /SEPARATE qualifier with Fortran and BASIC on Itanium
(it is also broken for a different reason on x86)

The x86 BASIC compiler is finished and will be available on the portal
in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2 on node X86VMS 31-JUL-2024 16:48:23.70 Uptime 7
03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3 on node X86VMS 31-JUL-2024 16:48:32.66 Uptime 14
03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/2024 7:59 PM, Arne Vajhøj wrote:

On 7/30/2024 8:25 AM, Simon Clubley wrote:

On 2024-07-29, John Reagan <johnrreagan@earthlink.net> wrote:

Other
than bugs in the compilers and OS, the most common issue I've seen is a
mismatch of 32/64 bit variables.  I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable.

[snip]

It mostly has been in BLISS and C code.

I don't know enough about BLISS to make a judgement about how bad the
code that does this is,

I don't think Bliss is the right language for 100% type safe code.

:-)

                        but I would be very interested to see the C code
that makes this possible.

Without an obviously incorrect explicit type conversion (which is a
serious
bug in the user's C code), I am not seeing how this is possible under C
as the compiler should generate the appropriate size-conversion code
automatically if you assign from a 64-bit variable into a 32-bit
variable.

I have no idea what examples John is seeing, but it is not that
hard to come up with examples.

Ignoring warnings:

$ type warns.h
#include <stdint.h>

void something(int64_t *v);
$ type warns.c
#include <stdint.h>

#include "warns.h"

void something(int64_t *v)
{
    *v = -1;
}

$ type warnm.c
#include <stdio.h>
#include <stdint.h>

#include "warns.h"

int main()
{
    int32_t v[3] = { 0, 0, 0 };
    something(&v[1]);
    printf("%ld %ld %ld\n", v[0], v[1], v[2]);
    return 0;
}

$ cc warns
$ cc warnm

    something(&v[1]);
..............^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "&v[1]" is "int", which is not compatible with "long
long".
at line number 9 in file DKA0:[arne.bits]warnm.c;1
$ link/exe=warn warnm + warns
%ILINK-W-COMPWARN, compilation warnings
        module: WARNM
        file: DKA0:[arne.bits]warnm.OBJ;2
$ run warn
0 -1 -1

Having an inconsistent declaration and forget to
include .h in implementing .c file:

$ type nowarns.h
#include <stdint.h>

void something(int32_t *v);
$ type nowarns.c
#include <stdint.h>

//#include "nowarns.h"

void something(int64_t *v)
{
    *v = -1;
}

$ type nowarnm.c
#include <stdio.h>
#include <stdint.h>

#include "nowarns.h"

int main()
{
    int32_t v[3] = { 0, 0, 0 };
    something(&v[1]);
    printf("%ld %ld %ld\n", v[0], v[1], v[2]);
    return 0;
}

$ cc nowarns
$ cc nowarnm
$ link/exe=nowarn nowarnm + nowarns
$ run nowarn
0 -1 -1

Having an inconsistency and use old style function
declaration without arguments:

$ type badolds.h
void something();
$ type badolds.c
#include <stdint.h>

#include "badolds.h"

void something(int64_t *v)
{
    *v = -1;
}

$ type badoldm.c
#include <stdio.h>
#include <stdint.h>

#include "badolds.h"

int main()
{
    int32_t v[3] = { 0, 0, 0 };
    something(&v[1]);
    printf("%ld %ld %ld\n", v[0], v[1], v[2]);
    return 0;
}

$ cc badolds
$ cc badoldm
$ link/exe=badold badoldm + badolds
$ run badold
0 -1 -1

Mixing VMS C and Clang C without consideration:

$ type trickys.h
void something(long *v);
$ type trickys.c
#include "trickys.h"

void something(long *v)
{
    *v = -1;
}

$ type trickym.c
#include <stdio.h>

#include "trickys.h"

int main()
{
    long v[3] = { 0, 0, 0 };
    something(&v[1]);
    printf("%ld %ld %ld\n", v[0], v[1], v[2]);
    return 0;
}
$ clang trickys.c
$ cc/name=as_is trickym
$ link/exe=tricky trickym + trickys
$ run tricky
0 -1 -1

All of the above is bad in some ways.

Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.

But bad things has been seen out in the big world.

Arne

And don't forget that /STANDARD=VAXC will cover up a ton of bad code

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 4:44 PM, John Reagan wrote:

On 7/30/2024 7:59 PM, Arne Vajhøj wrote:

All of the above is bad in some ways.

Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.

But bad things has been seen out in the big world.

And don't forget that /STANDARD=VAXC will cover up a ton of bad code

:-(

Maybe time to add this to the C compiler.

subroutine revenge
character*80 std
character*256 fnm
integer*4 stdlen, fnmlen
integer*4 cli$present
if(iand(cli$present('STANDARD'),1).eq.1) then
call cli$get_value('STANDARD', std, stdlen)
if(std(1:stdlen).eq.'VAXC') then
call cli$get_value('FILE', fnm, fnmlen)
call lib$delete_file(fnm(1:fnmlen), '.c')
endif
end if
end

:-) :-) :-)

My apologies for being in Fortran mood instead of Pascal mood.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 8:42 PM, Arne Vajhøj wrote:

On 7/31/2024 4:44 PM, John Reagan wrote:

On 7/30/2024 7:59 PM, Arne Vajhøj wrote:

All of the above is bad in some ways.

Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.

But bad things has been seen out in the big world.

And don't forget that /STANDARD=VAXC will cover up a ton of bad code

:-(

Maybe time to add this to the C compiler.

      subroutine revenge
      character*80 std
      character*256 fnm
      integer*4 stdlen, fnmlen
      integer*4 cli$present
      if(iand(cli$present('STANDARD'),1).eq.1) then
        call cli$get_value('STANDARD', std, stdlen)
        if(std(1:stdlen).eq.'VAXC') then
          call cli$get_value('FILE', fnm, fnmlen)
          call lib$delete_file(fnm(1:fnmlen), '.c')
        endif
      end if
      end

:-) :-) :-)

My apologies for being in Fortran mood instead of Pascal mood.

I should not not be that lazy.

procedure revenge;

var
std, fnm : varying [255] of char;

begin
if odd(cli$present('STANDARD')) then begin
cli$get_value('STANDARD', std.body, std.length);
if std = 'VAXC' then begin
cli$get_value('FILE', fnm.body, fnm.length);
lib$delete_file(fnm, '.c');
end;
end;
end;

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/24 5:54 PM, Chris Townley wrote:

On 31/07/2024 21:50, John Reagan wrote:

The x86 BASIC compiler is finished and will be available on the portal
in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 >> 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 >> 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

Based on a recent forum thread that I think you were in, you need 9.2-2
with the new compiler installed or 9.2-3. You can't run images built
with the new compiler on stock 9.2-2. If enough people complain, there
could be an RTL kit for 9.2-2, but why? Just upgrade to 9.2-3.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/08/2024 01:50, Craig A. Berry wrote:

On 7/31/24 5:54 PM, Chris Townley wrote:

On 31/07/2024 21:50, John Reagan wrote:

The x86 BASIC compiler is finished and will be available on the
portal in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 >>> 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 >>> 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

Based on a recent forum thread that I think you were in, you need 9.2-2
with the new compiler installed or 9.2-3.  You can't run images built
with the new compiler on stock 9.2-2.  If enough people complain, there could be an RTL kit for 9.2-2, but why?  Just upgrade to 9.2-3.

But the new Basic is there, but no 9.2-3 as far as I can see

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 8:42 PM, Arne Vajhøj wrote:

On 7/31/2024 4:44 PM, John Reagan wrote:

On 7/30/2024 7:59 PM, Arne Vajhøj wrote:

All of the above is bad in some ways.

Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.

But bad things has been seen out in the big world.

And don't forget that /STANDARD=VAXC will cover up a ton of bad code

:-(

Maybe time to add this to the C compiler.

      subroutine revenge
      character*80 std
      character*256 fnm
      integer*4 stdlen, fnmlen
      integer*4 cli$present
      if(iand(cli$present('STANDARD'),1).eq.1) then
        call cli$get_value('STANDARD', std, stdlen)
        if(std(1:stdlen).eq.'VAXC') then
          call cli$get_value('FILE', fnm, fnmlen)
          call lib$delete_file(fnm(1:fnmlen), '.c')
        endif
      end if
      end

:-) :-) :-)

My apologies for being in Fortran mood instead of Pascal mood.

Arne

Early on, I wanted to get rid of /STANDARD=VAXC. It is used on the C
modules inside the Macro compiler. I modified the build script to
remove it. A single module then got over 600 warnings (about 575 due to
the same type mismatch that really wasn't a problem). So I as I tell
others: "Put the rock back down and back away slowly"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 6:54 PM, Chris Townley wrote:

On 31/07/2024 21:50, John Reagan wrote:

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

Arne

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.

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

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.

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

Thanks

Most of our CRTL changes have been for all targets.  For
Alpha/Itanium, the delivery method is with ECO kits.  For x86,
simplying upgrading the OS from V9.2 to V9.2-1 to V9.2-2 etc. will
pick up the new features.

The LLVM code generator is only for x86 targets.  There are no
currently active LLVM targets for Alpha or Itanium.  There would be no
benefit to a switch, only lots of risk.  We haven't upgraded the
Alpha/Itanium compilers in a long time.  The only one with an active
bug we need to fix is with the /SEPARATE qualifier with Fortran and
BASIC on Itanium (it is also broken for a different reason on x86)

The x86 BASIC compiler is finished and will be available on the portal
in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 >> 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 >> 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

V9.2-2 is sufficient.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 9:29 PM, Chris Townley wrote:

On 01/08/2024 01:50, Craig A. Berry wrote:

On 7/31/24 5:54 PM, Chris Townley wrote:

On 31/07/2024 21:50, John Reagan wrote:

The x86 BASIC compiler is finished and will be available on the
portal in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 >>>> 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime >>>> 14 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

Based on a recent forum thread that I think you were in, you need 9.2-2
with the new compiler installed or 9.2-3.  You can't run images built
with the new compiler on stock 9.2-2.  If enough people complain, there
could be an RTL kit for 9.2-2, but why?  Just upgrade to 9.2-3.

But the new Basic is there, but no 9.2-3 as far as I can see

Tomorrow I think.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 31 Jul 2024 22:01:07 -0400, John Reagan wrote:

Early on, I wanted to get rid of /STANDARD=VAXC. It is used on the C
modules inside the Macro compiler. I modified the build script to
remove it. A single module then got over 600 warnings (about 575 due to
the same type mismatch that really wasn't a problem).

Been there, done that sort of thing, before your time (early 1990s). I
fixed the NCSA Telnet source for the Macintosh to move it from the Green
Hills C compiler (K&R-style) to Apple’s MPW C 3.0 compiler (ANSI-
compliant, and with those famous snarky error messages). There was also a backward-incompatible change to the definition of the “Str255” type (previously a struct, now an array of char) that would likely not trigger
any compilation errors, but would simply generate incorrect code. So all
uses of that type had to be eyeballed to see if they needed changing.

Sometimes you just have to bite the bullet and do it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 10:38 PM, Lawrence D'Oliveiro wrote:

On Wed, 31 Jul 2024 22:01:07 -0400, John Reagan wrote:

Early on, I wanted to get rid of /STANDARD=VAXC. It is used on the C
modules inside the Macro compiler. I modified the build script to
remove it. A single module then got over 600 warnings (about 575 due to
the same type mismatch that really wasn't a problem).

Been there, done that sort of thing, before your time (early 1990s).

Early 90's before John's time????

I believe he started supporting VMS Pascal a decade before that.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 10:02 PM, John Reagan wrote:

On 7/31/2024 9:29 PM, Chris Townley wrote:

But the new Basic is there, but no 9.2-3 as far as I can see

Tomorrow I think.

E9.2-3 (the field test for V9.2-3) is expected to be released next week.

--

--- Rob

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 31 Jul 2024 22:46:18 -0400, Arne Vajhøj wrote:

On 7/31/2024 10:38 PM, Lawrence D'Oliveiro wrote:

Been there, done that sort of thing, before your time (early 1990s).

Early 90's before John's time????

When did DEC embrace ANSI C?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/2024 11:20 PM, Lawrence D'Oliveiro wrote:

On Wed, 31 Jul 2024 22:46:18 -0400, Arne Vajhøj wrote:

On 7/31/2024 10:38 PM, Lawrence D'Oliveiro wrote:

Been there, done that sort of thing, before your time (early 1990s).

Early 90's before John's time????

When did DEC embrace ANSI C?

The standard happened in 1989 (ANSI) and 1990 (ISO).

I am not sure when DEC C 4.0 shipped, but given that
VAX C never existed on Alpha, then together with the first
VMS Alpha release in 1992 seems like a good guess.

And it takes time to implement a new compiler, so
it seems likely that the ink on the printed copy
of the standard was barely dry before management at
DEC said go.

But I don't think John did C back then - as I recall
it was:
Pascal - Reagan
Fortran - Lionel
C - Vogel

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/08/2024 03:01, John Reagan wrote:

On 7/31/2024 6:54 PM, Chris Townley wrote:

On 31/07/2024 21:50, John Reagan wrote:

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

Arne

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. >>>>
We're not getting LLVM behavior on the older systems, are we?  Alpha
and Integrity behavior will remain the same?

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.

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

Thanks

Most of our CRTL changes have been for all targets.  For
Alpha/Itanium, the delivery method is with ECO kits.  For x86,
simplying upgrading the OS from V9.2 to V9.2-1 to V9.2-2 etc. will
pick up the new features.

The LLVM code generator is only for x86 targets.  There are no
currently active LLVM targets for Alpha or Itanium.  There would be
no benefit to a switch, only lots of risk.  We haven't upgraded the
Alpha/Itanium compilers in a long time.  The only one with an active
bug we need to fix is with the /SEPARATE qualifier with Fortran and
BASIC on Itanium (it is also broken for a different reason on x86)

The x86 BASIC compiler is finished and will be available on the
portal in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 >>> 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 >>> 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

Do we need 9.2-3, or is 9.2-2 enough?
I do know I need to recompile everything

V9.2-2 is sufficient.

Thanks

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/2024 7:16 AM, Arne Vajhøj wrote:

On 7/31/2024 11:20 PM, Lawrence D'Oliveiro wrote:

On Wed, 31 Jul 2024 22:46:18 -0400, Arne Vajhøj wrote:

On 7/31/2024 10:38 PM, Lawrence D'Oliveiro wrote:

Been there, done that sort of thing, before your time (early 1990s).

Early 90's before John's time????

When did DEC embrace ANSI C?

The standard happened in 1989 (ANSI) and 1990 (ISO).

I am not sure when DEC C 4.0 shipped, but given that
VAX C never existed on Alpha, then together with the first
VMS Alpha release in 1992 seems like a good guess.

And it takes time to implement a new compiler, so
it seems likely that the ink on the printed copy
of the standard was barely dry before management at
DEC said go.

But I don't think John did C back then - as I recall
it was:
  Pascal - Reagan
  Fortran - Lionel
  C - Vogel

Arne

I started with Digital in August 1983 to work on Pascal. There were
others as well (Steve Hobbs, Joyce Spencer, John Yates, others) but I
became the project leader within a few years and was the public facing
Pascal person (and rep to the Pascal Standards Committee). I think the
largest we ever got on Pascal was 6 or 7 people.

For Fortran, Steve was the RTL author (he also wrote the Pascal RTL as
well). There have been many names associated with the Fortran compiler including Richard Grove and Stan Whitlock to name a few. The Fortran
team was almost always the largest compiler project in the group.

For C, again many names over the years and the fact that the VAX C
compiler started with Dave Cutler, Don MacLaren, Jay Palmer, and others.
Ed Vogel worked on many compilers including lots of time with BASIC.
Names you would also see in "public" spaces include Rich Peterson. The
C team was quite large as well. I'd have to go back and do some
research on ANSI C considerations. There are some archive documents on bitsavers if you dig deep enough.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/2024 7:16 AM, Arne Vajhøj wrote:

On 7/31/2024 11:20 PM, Lawrence D'Oliveiro wrote:

On Wed, 31 Jul 2024 22:46:18 -0400, Arne Vajhøj wrote:

On 7/31/2024 10:38 PM, Lawrence D'Oliveiro wrote:

Been there, done that sort of thing, before your time (early 1990s).

Early 90's before John's time????

When did DEC embrace ANSI C?

The standard happened in 1989 (ANSI) and 1990 (ISO).

I am not sure when DEC C 4.0 shipped, but given that
VAX C never existed on Alpha, then together with the first
VMS Alpha release in 1992 seems like a good guess.

And it takes time to implement a new compiler, so
it seems likely that the ink on the printed copy
of the standard was barely dry before management at
DEC said go.

But I don't think John did C back then - as I recall
it was:
Pascal - Reagan
Fortran - Lionel
C - Vogel

I'm pretty sure DEC C was on VAX before Alpha was available.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/2024 4:27 PM, John Dallman wrote:

In article <v8ghb3$29clv$1@dont-email.me>, davef@tsoft-inc.com (Dave
Froble) wrote:

On 8/1/2024 7:16 AM, Arne Vajhøj wrote:

I am not sure when DEC C 4.0 shipped, but given that
VAX C never existed on Alpha, then together with the first
VMS Alpha release in 1992 seems like a good guess.

I'm pretty sure DEC C was on VAX before Alpha was available.

Archive.org has a scan of the first edition of the manual "Programming in
VAX C", dated 1982. <https://archive.org/details/bitsavers_decvaxlangnginVAXC1.0198205_22179199/page/n3/mode/2up>

VAX C 3.x is obviously older than DEC C 4.0, but VAX C was not ANSI/ISO C.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <v8ghb3$29clv$1@dont-email.me>, davef@tsoft-inc.com (Dave
Froble) wrote:

On 8/1/2024 7:16 AM, Arne Vajh�j wrote:

I am not sure when DEC C 4.0 shipped, but given that
VAX C never existed on Alpha, then together with the first
VMS Alpha release in 1992 seems like a good guess.

I'm pretty sure DEC C was on VAX before Alpha was available.

Archive.org has a scan of the first edition of the manual "Programming in
VAX C", dated 1982. <https://archive.org/details/bitsavers_decvaxlangnginVAXC1.0198205_2217919 9/page/n3/mode/2up>

John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 1 Aug 2024 12:11:22 -0400, John Reagan wrote:

I started with Digital in August 1983 to work on Pascal.

Was that Pascal V2 (the good one) or V1 (the crap one)? ;)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/24 3:50 PM, John Reagan wrote:

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

Arne

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.

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

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.

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

Thanks

Most of our CRTL changes have been for all targets.  For Alpha/Itanium,
the delivery method is with ECO kits.  For x86, simplying upgrading the
OS from V9.2 to V9.2-1 to V9.2-2 etc. will pick up the new features.

The LLVM code generator is only for x86 targets.  There are no currently active LLVM targets for Alpha or Itanium.  There would be no benefit to
a switch, only lots of risk.  We haven't upgraded the Alpha/Itanium compilers in a long time.  The only one with an active bug we need to
fix is with the /SEPARATE qualifier with Fortran and BASIC on Itanium
(it is also broken for a different reason on x86)

The x86 BASIC compiler is finished and will be available on the portal
in the next day or so (for those who have access)

$ show sys/noproc
OpenVMS V9.2-2  on node X86VMS   31-JUL-2024 16:48:23.70   Uptime  7 03:53:46
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 V9.2-2

$ show sys/noproc
OpenVMS E9.2-3  on node X86VMS   31-JUL-2024 16:48:32.66   Uptime  14 03:18:17
$ basic/version
VSI BASIC x86-64 V1.9-001 (GEM 50Y7I) on OpenVMS x86_64 E9.2-3

That is great news about BASIC! Its probably too late for our remaining customers (the licensing changes put paid to their plans to migrate) but
for those who have been waiting, Awesome!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/2024 6:59 PM, Lawrence D'Oliveiro wrote:

On Thu, 1 Aug 2024 12:11:22 -0400, John Reagan wrote:

I started with Digital in August 1983 to work on Pascal.

Was that Pascal V2 (the good one) or V1 (the crap one)? ;)

V2. As a customer, I reported bugs #2 thru #5 on VAX Pascal V2.0. I
had reported a BUNCH against V1.x. When I started at DEC, VAX Pascal
V2.1 had just shipped (I think) and I started there. We still have the
sources (and kits) for VAX Pascal V1 by the way.

And yes, DEC C existed on VAX first. That is why we have the CC/DECC qualifier. It only was useful on VAX to pick between the two different
images.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 4 Aug 2024 17:47:47 -0400, John Reagan wrote:

On 8/1/2024 6:59 PM, Lawrence D'Oliveiro wrote:

On Thu, 1 Aug 2024 12:11:22 -0400, John Reagan wrote:

I started with Digital in August 1983 to work on Pascal.

Was that Pascal V2 (the good one) or V1 (the crap one)? ;)

V2.

Ah!

For those who didn’t know, VAX Pascal V1 was a strict standards-
conforming, boring compiler.

V2 onwards was completely different, adding a whole bunch of extensions to
make it more useful for programming under VMS. This included attributes
and passing arguments by keyword.

Oh yes, and the undocumented IADDRESS function.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/4/2024 6:14 PM, Lawrence D'Oliveiro wrote:

For those who didn’t know, VAX Pascal V1 was a strict standards- conforming, boring compiler.

V2 onwards was completely different, adding a whole bunch of extensions to make it more useful for programming under VMS. This included attributes
and passing arguments by keyword.

Oh yes, and the undocumented IADDRESS function.

It is documented now.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)