Front page | perl.perl5.porters |
Postings from May 2021
From: Nicholas Clark
May 20, 2021 07:59
Message ID: 20210520075853.GZ16703@etla.org
On Wed, May 19, 2021 at 08:43:29PM -0500, Craig A. Berry wrote:
> On Wed, May 19, 2021 at 8:31 AM Nicholas Clark <email@example.com> wrote:
> tl;dr, all 8 test programs compile without warning or error on:
> $ cc/version
> VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1
Thanks. I updated https://github.com/Perl/perl5/wiki/C99
And it seems that the result is:
What we can use depends on the minimum MSVC version that we choose.
although your detail below says that we really can't assume *anything*
else much about header or runtime library support on VMS, without asking
> > Sadly the VMS test system at 220.127.116.11 on which I once had an account
> > is no longer live, so I can't directly test things on VMS.
> You could just ask me like everyone else does :-). Or if you ssh to
This doesn't scale that well...
(I think we both know that)
The 8 programs in question were actually battle tested on 3 OSes (and 4
compilers) and various bugs found before they even got attached.
"batch mode" isn't that useful for testing, until the kinks are ironed
out, and usually the sort of things I'm curious about are kinky and
involve ironing. (And somehow this is fun? I still don't get that bit)
> eisner.decus.org, you can sign up for a free account on an Alpha, but
> Alphas are rather slow by current standards and I'm not sure how easy
> it would be to get enough disk space to build Perl. Small test
> programs should be ok, though.
This is a *real* Alpha? I don't think that anyone else offers one of
those. That's actually useful even for (other) test programs, as I can't
remember what the alignment constraints (and similar) are for Alpha.
qemu isn't *ideal*, as it emulates "correct" behaviour "correctly".
So you can't find misaligned reads because it won't check for those, and
if it's running on something more forgiving (ie x86_64) it will fail to
fail. (undefined behaviour in C anyway, so it's legally correct. But on
real hardware this sort of thing is usually a SIGBUS)
sparc64 had been my current "winner" (ppc64 seems to handle misaligned
8 byte reads, whereas sparc64 does not), but until Merijn set me up
again on HP-UX yesterday I'd not had access to ia64, so I've not been
figuring out what it gets grumpy about.
(ia64 linux was fun, but the GCC farm no longer has that. The memory
map broke some assumptions for some code. Win. I think they had parisc
linux too once, but it seems that no-one is offering parisc anything
currently. I've never had access to test things on 64 bit IBM
hardware, and only very brief access to SuperH. Whichever OS that was
had the suckiest command line toolchain ever.)
> In a month or two there should be an early adopters' kit for OpenVMS
> x64 that is expected to run on VirtualBox/KVM/VMWare. That should make
> it easier to try things out at home.
I don't own any x86_64 hardware* :-)
> The C99 situation on VMS, like everything else, is just a bit weirder
> than elsewhere. The compiler has mostly supported C99 for well over a
> decade (closer to two), while the library has been somewhat lacking in
> various areas, but of course the standard has never distinguished
> between the compiler and the library.
IIRC this was always the problem with C99 conformance. gcc got "there"
way ahead of glibc. And re-reading Merijn's comments about building
gcc on HP-UX, along with looking for stuff online, it seems that gcc
needs a C99 "compiler" to bootstrap, and the gcc probes figure out
that HP-UX *libc* was missing parts of C99. And so we get to:
> Last year there was a patch that finally introduced stdint.h, moving
> to it a lot of things that had been in inttypes.h and supplying a lot
> of things that were missing. fpclassify() got some attention and the
> %z format specifier finally became available. va_copy is still not
> available, but is expected to be on x86_64. I cannot find a link to
> public release notes that describe the current state of things, but as
> far as I can tell, nothing being contemplated in the 8 test programs
> posted here is impacted by recent or near-term future changes.
That's nuts. '%z' can't have been *hard* work - sure, *printf C
implementations are never pretty, but 'z' will be an alias to a different
format letter. Presumably as supported VMS is all LP64, 'z' is just 'l'.
But isn't <stdint.h> just *tabulating* existing type and format string
knowledge into a standard form? It doesn't *need* any runtime additions,
* strictly "any hardware capable of running a 64 bit kernel and VMs".
Even if working, which I'm not sure about either.