From a VSI post on LinkedIn:

"The candidate build was completed on 16 June, the goal is to make this
the final release for 9.2 and to ship any fixes as patch kits."

<https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>

John

Den 2022-06-29 kl. 10:06, skrev John Dallman:
> From a VSI post on LinkedIn:
>
> "The candidate build was completed on 16 June, the goal is to make this
> the final release for 9.2 and to ship any fixes as patch kits."
>
> <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>
>
> John

Yes, Also got that as a mail notification.
But the linked release notes are still from March, so I was
not sure what the "news" was about and ignored this...

On Wednesday, June 29, 2022 at 5:21:02 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2022-06-29 kl. 10:06, skrev John Dallman:
> > From a VSI post on LinkedIn:
> >
> > "The candidate build was completed on 16 June, the goal is to make this
> > the final release for 9.2 and to ship any fixes as patch kits."
> >
> > <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>
> >

The notes about va_copy are interesting. Presumably, the v*printf functions in the
C RTL still work, so the compiler knows how to pass a va_list to another routine
but it can't copy it to another va_list.

The note on short data in IA64 protected images is a little disturbing. A protected
image ported to X86 may break because it was (possibly inadvertently) doing
something unsafe?

On Wednesday, June 29, 2022 at 7:29:00 AM UTC-4, osuv...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 5:21:02 AM UTC-4, Jan-Erik Söderholm wrote:
> > Den 2022-06-29 kl. 10:06, skrev John Dallman:
> > > From a VSI post on LinkedIn:
> > >
> > > "The candidate build was completed on 16 June, the goal is to make this
> > > the final release for 9.2 and to ship any fixes as patch kits."
> > >
> > > <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>
> > >
> The notes about va_copy are interesting. Presumably, the v*printf functions in the
> C RTL still work, so the compiler knows how to pass a va_list to another routine
> but it can't copy it to another va_list.
>
Copying a va_list has always been something that should have used va_copy()..
You can cheat with a direct assigment of va_list's on VAX, Alpha, and Itanium
since va_lists are just arrays of pointers. That isn't true on x86. A va_list is a
struct with some fields, several pointers, and more. You have to ask the
compiler to do that for you with the va_copy() intrinsic. That is what every
piece of opensource code on Linux does today (or it wouldn't work). Added
to the problem is that the va_copy from C99 was only added into the headers
by VSI. (On Alpha & Itanium, it just expands into an assignment. On x86, it is
a real intrinsic that we have to pass along to LLVM).

And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
if you are still using it. The model presented to us by LLVM is the stdarg model.
We have to do extra work to hack up varargs.

> The note on short data in IA64 protected images is a little disturbing. A protected
> image ported to X86 may break because it was (possibly inadvertently) doing
> something unsafe?
No, that release note just attempts to describe that unlike Itanium with had a single
short section with linker-generated address constants, there may now be multiple
GOTs (Global Offset Table) in a single image, one per cluster. Most normal images
only have one cluster (you have to use explicit linker options to split it up).

On Itanium, all routines get a GP (Global Pointer) passed in so a routine can find
all the address constants. On x86, there is nothing passed in. It has to know the
distance from the code to the GOT. The linker-create GOT (again, one per cluster)
is another image segment at a fixed offset from the code. If you move the code,
you have to move the associated GOT. Nothing really unique to OpenVMS other
than perhaps having an image with some code in 64-bit space and some code
in 32-bit space. If you read the AMD64 ABI, that isn't the "small" or "medium"
or "large" memory model. We are sorta like "medium" with some pieces from
the "large" memory model where we always go thru the GOT to find all static
data and to find other routines in the same module (but might be in different
code PSECTs).

On 2022-06-29, John Reagan <xyzzy1959@gmail.com> wrote:
> On Wednesday, June 29, 2022 at 7:29:00 AM UTC-4, osuv...@gmail.com wrote:
>> On Wednesday, June 29, 2022 at 5:21:02 AM UTC-4, Jan-Erik Söderholm wrote:
>> > Den 2022-06-29 kl. 10:06, skrev John Dallman:
>> > > From a VSI post on LinkedIn:
>> > >
>> > > "The candidate build was completed on 16 June, the goal is to make this
>> > > the final release for 9.2 and to ship any fixes as patch kits."
>> > >
>> > > <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>
>> > >
>> The notes about va_copy are interesting. Presumably, the v*printf functions in the
>> C RTL still work, so the compiler knows how to pass a va_list to another routine
>> but it can't copy it to another va_list.
>>
> Copying a va_list has always been something that should have used va_copy().
> You can cheat with a direct assigment of va_list's on VAX, Alpha, and Itanium
> since va_lists are just arrays of pointers. That isn't true on x86. A va_list is a
> struct with some fields, several pointers, and more. You have to ask the
> compiler to do that for you with the va_copy() intrinsic. That is what every
> piece of opensource code on Linux does today (or it wouldn't work). Added
> to the problem is that the va_copy from C99 was only added into the headers
> by VSI. (On Alpha & Itanium, it just expands into an assignment. On x86, it is
> a real intrinsic that we have to pass along to LLVM).
>

So there are some bits of broken user code that you (VSI) can't work around.

I've absolutely no problem with that - it's the broken code that needs
to be fixed.

Conceptually, it's no different from the user code had to be fixed when
people switched from VAX C to DEC C.

> And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
> if you are still using it. The model presented to us by LLVM is the stdarg model.
> We have to do extra work to hack up varargs.
>

That message is an excellent candidate for a note-level informational
message for the compiler to output.

BTW, I see that TECO is not available. How did you avoid the mutiny ? :-)

Simon.

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

On Wednesday, June 29, 2022 at 9:07:24 AM UTC-4, Simon Clubley wrote:

> > And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
> > if you are still using it. The model presented to us by LLVM is the stdarg model.
> > We have to do extra work to hack up varargs.
> >
> That message is an excellent candidate for a note-level informational
> message for the compiler to output.
>
No need to get the compiler involved, just a #pragma message in the header.

On 6/29/2022 11:21 AM, John Reagan wrote:
> On Wednesday, June 29, 2022 at 9:07:24 AM UTC-4, Simon Clubley wrote:
>>> And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
>>> if you are still using it. The model presented to us by LLVM is the stdarg model.
>>> We have to do extra work to hack up varargs.
>>>
>> That message is an excellent candidate for a note-level informational
>> message for the compiler to output.
>>
> No need to get the compiler involved, just a #pragma message in the header.

Like:

#pragma message("Quiz time! What year did this header file become
obsolete? A: 1989 B: 1999 C: 2011 While thinking please use the time to
change the include!")

:-)

Arne

On Wednesday, June 29, 2022 at 5:53:04 AM UTC-7, xyzz...@gmail.com wrote:
> Copying a va_list has always been something that should have used va_copy().
> You can cheat with a direct assigment of va_list's on VAX, Alpha, and Itanium
> since va_lists are just arrays of pointers. That isn't true on x86. A va_list is a
> struct with some fields, several pointers, and more. You have to ask the
> compiler to do that for you with the va_copy() intrinsic. That is what every
> piece of opensource code on Linux does today (or it wouldn't work). Added
> to the problem is that the va_copy from C99 was only added into the headers
> by VSI. (On Alpha & Itanium, it just expands into an assignment. On x86, it is
> a real intrinsic that we have to pass along to LLVM).
>
> And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
> if you are still using it. The model presented to us by LLVM is the stdarg model.
> We have to do extra work to hack up varargs.

Thanks for the info: now I know that it's safe to replace va_copy() with an assignment on Alpha & Itanium with the current V7.4 compilers. The current <stdarg.h> has:

#if !defined(__x86_64) /* Verified for x86, John Reagan */
....
#if defined(__DECC) && (__DECC_VER >= 70500000)
#define va_copy(cp, ap) cp = (__va_list) ((__char_ptr32) __VA_COPY_BUILTIN(ap))
#endif
#endif

#if defined(__x86_64) /* Verified for x86, John Reagan */
....
#if !defined (__DECCXX)
#define va_copy(cp, ap) cp = __VA_COPY_BUILTIN(ap)
#endif
#endif

So I have to define my own va_copy() in the meantime.

On 2022-06-29, John Reagan <xyzzy1959@gmail.com> wrote:
> On Wednesday, June 29, 2022 at 9:07:24 AM UTC-4, Simon Clubley wrote:
>
>> > And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
>> > if you are still using it. The model presented to us by LLVM is the stdarg model.
>> > We have to do extra work to hack up varargs.
>> >
>> That message is an excellent candidate for a note-level informational
>> message for the compiler to output.
>>
> No need to get the compiler involved, just a #pragma message in the header.
>

If it's a pragma in a header that's triggered when the function is used,
then I do consider that to be part of the compiler. :-)

Simon.

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

On Wednesday, June 29, 2022 at 2:07:24 PM UTC+1, Simon Clubley wrote:
> On 2022-06-29, John Reagan <xyzz...@gmail.com> wrote:
> > On Wednesday, June 29, 2022 at 7:29:00 AM UTC-4, osuv...@gmail.com wrote:
> >> On Wednesday, June 29, 2022 at 5:21:02 AM UTC-4, Jan-Erik Söderholm wrote:
> >> > Den 2022-06-29 kl. 10:06, skrev John Dallman:
> >> > > From a VSI post on LinkedIn:
> >> > >
> >> > > "The candidate build was completed on 16 June, the goal is to make this
> >> > > the final release for 9.2 and to ship any fixes as patch kits."
> >> > >
> >> > > <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/>
> >> > >
> >> The notes about va_copy are interesting. Presumably, the v*printf functions in the
> >> C RTL still work, so the compiler knows how to pass a va_list to another routine
> >> but it can't copy it to another va_list.
> >>
> > Copying a va_list has always been something that should have used va_copy().
> > You can cheat with a direct assigment of va_list's on VAX, Alpha, and Itanium
> > since va_lists are just arrays of pointers. That isn't true on x86. A va_list is a
> > struct with some fields, several pointers, and more. You have to ask the
> > compiler to do that for you with the va_copy() intrinsic. That is what every
> > piece of opensource code on Linux does today (or it wouldn't work). Added
> > to the problem is that the va_copy from C99 was only added into the headers
> > by VSI. (On Alpha & Itanium, it just expands into an assignment. On x86, it is
> > a real intrinsic that we have to pass along to LLVM).
> >
> So there are some bits of broken user code that you (VSI) can't work around.
>
> I've absolutely no problem with that - it's the broken code that needs
> to be fixed.
>
> Conceptually, it's no different from the user code had to be fixed when
> people switched from VAX C to DEC C.
> > And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
> > if you are still using it. The model presented to us by LLVM is the stdarg model.
> > We have to do extra work to hack up varargs.
> >
> That message is an excellent candidate for a note-level informational
> message for the compiler to output.
>
> BTW, I see that TECO is not available. How did you avoid the mutiny ? :-)
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

No teco! Andy Goldstein must have really retired ;-)