Some of my old work-arounds for missing <stdint.h> (and its friends),
for example, my declarations of [u]intmax_t, now conflict with those in
the new <stdint.h>.

Is there a C macro which would reveal whether <stdint.h> exists,
and/or <inttypes.h> has some actual content, and so on? Perhaps a test
like: "__STDC_VERSION__ >= 199901"?

Here, "new" means something like "VSI C V7.4-001 on OpenVMS IA64
V8.4-2L3", and "not new" would be something from HP[E] which I can't
easily run now. I'd prefer to keep things working in older
environments, but I might be too lazy to use a "configure" script to
deal with this stuff.

Is there some documentation where I should have found this already?

On 6/20/2022 5:20 PM, Steven Schweda wrote:
> Some of my old work-arounds for missing <stdint.h> (and its friends),
> for example, my declarations of [u]intmax_t, now conflict with those in
> the new <stdint.h>.
>
> Is there a C macro which would reveal whether <stdint.h> exists,
> and/or <inttypes.h> has some actual content, and so on? Perhaps a test
> like: "__STDC_VERSION__ >= 199901"?
>
> Here, "new" means something like "VSI C V7.4-001 on OpenVMS IA64
> V8.4-2L3", and "not new" would be something from HP[E] which I can't
> easily run now. I'd prefer to keep things working in older
> environments, but I might be too lazy to use a "configure" script to
> deal with this stuff.
>
> Is there some documentation where I should have found this already?

I believe that it is quite common to have fancy tools that run
and figure stuff like this out and generate a header file with
the right environment specific macros for the real code as first
part of the build process.

This tells me that either some smart people have missed something
or that it is a hard problem.

Arne

On 6/20/22 4:20 PM, Steven Schweda wrote:
> Some of my old work-arounds for missing <stdint.h> (and its friends),
> for example, my declarations of [u]intmax_t, now conflict with those in
> the new <stdint.h>.
>
> Is there a C macro which would reveal whether <stdint.h> exists,
> and/or <inttypes.h> has some actual content, and so on? Perhaps a test
> like: "__STDC_VERSION__ >= 199901"?
>
> Here, "new" means something like "VSI C V7.4-001 on OpenVMS IA64
> V8.4-2L3", and "not new" would be something from HP[E] which I can't
> easily run now. I'd prefer to keep things working in older
> environments, but I might be too lazy to use a "configure" script to
> deal with this stuff.
>
> Is there some documentation where I should have found this already?

I haven't tried it but most likely with:

#if __CRTL_VER < 80500000
// do stuff that collides with C99 ECO
#endif

They weren't initially going to bump the CRTL version with the C99 ECO,
but I think by the final release ended up doing so.

Or you can disable the C99 changes by compiling with:

CC/DEFINE=(__CRTL_VER_OVERRIDE=80400000)

My first attempt used "__STDC_VERSION__ >= 199901" to decide whether
to expect <stdint.h>, and, following the usual hints in the header
files, "__CRTL_VER >= 80500000" for the actual run-time stuff. This
almost worked.

In the IA64 -> x86_64 cross-tools (X86_XTOOLS E9.2-XG6F) headers,
<string.h> has this helpful morsel:

# if __CRTL_VER >= 80500000
char *strndup(__const_char_ptr64, __size_t);
int strerror_r(int, __char_ptr64, __size_t);
char *stpcpy(char *, __const_char_ptr64);
# define mempcpy(to, from, len) (void *)((char *)memcpy((to), (from),
(len)) + (len))
# endif

So mempcpy() works that way. But my plain-old IA64 <string.h> lacks the
mempcpy() part of that, leading to fatal complaints.

ITS $ cc /vers
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L3
__STDC_VERSION__ = 199901
__CRTL_VER = 80500000

V86 $ [...]
V86 $ run stdc_vers ! x86_64
__STDC_VERSION__ = 199901
__CRTL_VER = 80500000

Am I missing a patch for the IA64 C headers, or is the x86 stuff
expected to make more sense than the IA64 stuff? I can fake the
mempcpy() stuff missing from <string.h>, but if it's all already
straightened out (or is about to be), then I'd rather avoid the clutter.

> I believe that it is quite common to have fancy tools [...]

Sure, but not on VMS.

I had a similar issue with getrusage() now being available in the X86_64 CRTL.

> I had a similar issue with getrusage() now being available in the X86_64 CRTL.

But in that case, <resource.h> agrees between IA64 and x86_64. (So I
assume that it's also available on IA64, now, too.)

I suppose that I can use the formal field-test complaint mechanism to
complain about the difference, even though I'd place the defect on the
IA64 side.

On 2022-06-20 21:20:27 +0000, Steven Schweda said:

> Is there a C macro which would reveal whether <stdint.h> exists,
> and/or <inttypes.h> has some actual content, and so on? Perhaps a test
> like: "__STDC_VERSION__ >= 199901"?

No. Not absent checks in the build procedure. The compiler itself has
been C99 for a very long time, but the non-compiler pieces only arrived
within the last several years.

I'd prefer to shift the complexity from the folks building for new to
the folks building for old, and would assume C99 everywhere and with
stdint.h present, and would make the user specify a procedure build
parameter to request an "old" build.

Which might then select CC /DEFINE=LEGACY_HPE_COMPATIBILITY=1 or ilk.

Go for better defaults and cleaner code long-term, and #if-highlight
the hunks of C code that'll get expunged first. Make it easier to rip
out the added complexity.

I might add a #if __STDC_VERSION__ >= 199901 defensive check or two
into the C source code, should some intrepid code retronaut go
particularly deep into the weeds.

This all given OpenVMS V8.4 is a dozen years back, given there's no HPE
hobbyist licenses, given (AFAIK) VSI hobbyists currently have access to
VSI C99, and given OpenVMS x86-64 Clang is C17 and won't have this
stdint.h mess, and given there's no way VSI is going to emulate the
busted C99 giblets within the context of the legacy-compatible C
compiler.

--
Pure Personal Opinion | HoffmanLabs LLC

вторник, 21 июня 2022 г. в 07:37:57 UTC+3, Steven Schweda:

> Am I missing a patch for the IA64 C headers, or is the x86 stuff
> expected to make more sense than the IA64 stuff?

Yes, you are missing a CRTL patch (IMO will be enough CRTL ECO3)

On Wednesday, June 22, 2022 at 8:16:38 AM UTC-4, Vitaly Pustovetov wrote:
> вторник, 21 июня 2022 г. в 07:37:57 UTC+3, Steven Schweda:
> > Am I missing a patch for the IA64 C headers, or is the x86 stuff
> > expected to make more sense than the IA64 stuff?
> Yes, you are missing a CRTL patch (IMO will be enough CRTL ECO3)
I think it was ECO5 that added it to IA64. I'm not a huge fan of adding functionality
with ECO kits but that is the plan at the moment.

On 2022-06-22 14:34:11 +0000, John Reagan said:

> I'm not a huge fan of adding functionality with ECO kits but that is
> the plan at the moment.

Neither am I, but no new versions on the existing VSI platforms, so
that means any new features or enhancements via ECO or UPDATE kits.

Various new capabilities and features were added in a number of the
V8.4 UPDATE kits too, and were (only) documented in the patch notes.

That was the enhancement strategy for ~five years or more, too.
Unfortunately, the (published) HPE documentation set was not updated.

Whether the HP and HPE V8.4 UPDATE patch notes are now reflected in the
VSI doc, or if those late-era changes are now nearly forgotten, I've
not checked.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-06-22, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-06-22 14:34:11 +0000, John Reagan said:
>
>> I'm not a huge fan of adding functionality with ECO kits but that is
>> the plan at the moment.
>
> Neither am I, but no new versions on the existing VSI platforms, so
> that means any new features or enhancements via ECO or UPDATE kits.
>

Then stick the new functionality in an UPDATE kit if those are the
only options.

Placing it in an ECO kit is wrong and I would have thought that VSI
would realise that, based on past history.

Also, the UPDATE kit release notes should be part of the public VMS
documentation so that the information they contain never gets "lost".

> Various new capabilities and features were added in a number of the
> V8.4 UPDATE kits too, and were (only) documented in the patch notes.
>
> That was the enhancement strategy for ~five years or more, too.
> Unfortunately, the (published) HPE documentation set was not updated.
>
> Whether the HP and HPE V8.4 UPDATE patch notes are now reflected in the
> VSI doc, or if those late-era changes are now nearly forgotten, I've
> not checked.
>

IIRC, VSI choose not to take some of the more recent HPE work at the
time VSI was formed.

Simon.

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

> Yes, you are missing a CRTL patch (IMO will be enough CRTL ECO3)

> I think it was ECO5 that added it to IA64. I'm not a huge fan of adding functionality
> with ECO kits but that is the plan at the moment.

I reported the difference to VSI, and am told that
I64-VMS842L3I_RTL-V0500 should do it. Sadly, the closest thing I found
in the Community collection was VSI-I64VMS-VMS842L1I_RTL-V0500--4, but
that resists installation "on OpenVMS IA64 V8.4-2L3".

I'll see if I can persuade someone to make the newer stuff made more
peon-accessible.

Thanks to all for the info.

On 2022-06-22 17:20:04 +0000, Simon Clubley said:

> On 2022-06-22, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2022-06-22 14:34:11 +0000, John Reagan said:
>>
>>> I'm not a huge fan of adding functionality with ECO kits but that is
>>> the plan at the moment.
>>
>> Neither am I, but no new versions on the existing VSI platforms, so
>> that means any new features or enhancements via ECO or UPDATE kits.
>>
>
> Then stick the new functionality in an UPDATE kit if those are the only
> options.
>
> Placing it in an ECO kit is wrong and I would have thought that VSI
> would realise that, based on past history.
>
> Also, the UPDATE kit release notes should be part of the public VMS
> documentation so that the information they contain never gets "lost".

All patch notes should be part of the public doc, either as patch
notes, or incorporated into the documentation. As marketing tools, too.

Determining when features got added is already a manual process within
the V8.4 series.

I too don't like updates via patch kits. But that's where we are,
pending any future UPDATE kits, and any (entirely hypothetical)
maintenance releases for Alpha and Itanium.

But I really don't want to see the LOGINOUT mess, or other feature
forks, either.

>> Various new capabilities and features were added in a number of the
>> V8.4 UPDATE kits too, and were (only) documented in the patch notes.
>>
>> That was the enhancement strategy for ~five years or more, too.
>> Unfortunately, the (published) HPE documentation set was not updated.
>>
>> Whether the HP and HPE V8.4 UPDATE patch notes are now reflected in the
>> VSI doc, or if those late-era changes are now nearly forgotten, I've
>> not checked.
>>
>
> IIRC, VSI choose not to take some of the more recent HPE work at the
> time VSI was formed.

Which only complicates matters.

--
Pure Personal Opinion | HoffmanLabs LLC

On 6/24/22 4:23 PM, Stephen Hoffman wrote:
> On 2022-06-22 17:20:04 +0000, Simon Clubley said:

>> IIRC, VSI choose not to take some of the more recent HPE work at the
>> time VSI was formed.
>
> Which only complicates matters.

It does, but some of it really wasn't ready for prime time. Like the
domain socket emulation that required system-level logical names to
specify something (I think it was the port range).