On 2022-05-19 21:21:02 +0000, Jake Hamby said:

> On Thursday, May 19, 2022 at 12:11:43 PM UTC-7, Stephen Hoffman wrote:
>>
>> Clang building with C18 / C2X with diagnostics lit (clang -Wall, maybe
>> also with -Wextra) produces more reliable code.
>> VSI C with /STANDARD=C99 /WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT,
>> QUESTCODE, ...), DISABLE=(...)) does well at finding trouble. Adding
>> VERBOSE and OVERFLOW can be useful, too.
>>
>
> I completely agree with everything you said, and thanks for the
> suggestion of useful warnings to enable.
>

For projects ranging from refactoring to a full overhaul, consider
adding preprocessor #define commands to cause certain entirely valid
but too-often problematic C calls to generate errors. (e.g. sprintf,
strcat, strcpy, etc)

https://en.wikipedia.org/wiki/C_standard_library#Buffer_overflow_vulnerabilities

Not yet part of ANSI/ISO C, but strlcat and strlcpy and ilk are locally
preferred to the strr* calls, as the latter are problematic around
string termination.

Since this is comp.os.vms, and when portability is not an issue, string
descriptors can be an option. Native OpenVMS C support for descriptors
is limited, however. That support is somewhat less opaque than one
might prefer. Objective C has some related enhancements here, but those
well past descriptors in its capabilities. Assuming run-time
message-passing support of course, which OpenVMS lacks. It'll be
interesting to see how OpenVMS does with blocks, as that extension was
already part of Clang when last I checked.

>
>> There can be good VAX C code. It's just... very rarely encountered. If
>> OpenVMS C code is now compiling with /STANDARD=VAXC, then somebody
>> noticed the C diagnostics, and decided to ignore them.
>
> Fortunately, I haven't run into that particular issue!
>

You're seemingly mostly working with cross-platform code. That has
probably been mostly-scrubbed of K&R C. A little more scrubbing is
probably arriving with C2X, with the function declaration syntax
deprecation.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/20/22 3:17 PM, Jake Hamby wrote:
> On Thursday, May 19, 2022 at 7:25:58 PM UTC-7, Craig A. Berry wrote:

>> For a faster pipe implementation see dmpipe, which uses
>> global sections:
>>
>> https://sourceforge.net/p/vms-ports/dmpipe
>>
>> Unfortunately this involves wrapping pretty much every function in the
>> CRTL that touches a file descriptor -- the fix should really be inside
>> the CRTL, but, alas, that also is not on the roadmap.

> Aha, that's where I should look for a faster pipe implementation,
> thanks! I saw something similar to dmpipe in the GNV bash port
> ("vms_vm_pipe.c"), but it didn't come with docs or test programs, so I
> didn't want to use that version.

I'm pretty sure that one is just using heap memory to do its own
buffering around a mailbox pipe, but I confess I've never looked at it
in any detail.

dmpipe uses global sections, which is really what the CRTL should have
switched to decades ago. I believe the VMS port of Apache uses sockets,
but it involves installing an image with privileges in order to be able
to bump the socket buffer size above the puny 255-byte default.
> The code that I need to update, to finish making Regina useful again
> on VMS, is reviving the original author's code to call lib$spawn()
> with the NOWAIT flag to execute DCL commands and redirect their
> SYS$INPUT and SYS$OUTPUT.
>
> It'd be nice if I could use the vfork()/execvp() code that I wrote,
> but it only works for .exe and .com files, not DCL commands.
There is some stuff in the Perl sources that tries to figure out whether
the thing it's been sent is an image name or a DCL command:

https://github.com/Perl/perl5/blob/blead/vms/vms.c#L10520

On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:

> Why didn't ANSI fix some of the problems like null terminated strings,
> requiring bounds checking, etc. when they had the chance?

Just a guess: probably because the C committee is not entirely
comprised of pendejos.

While the C committee could make such changes, those changes would
break enough existing C code that there'd be little reason not to break
yet more of the existing C programs.

Which then means this new C-family language would be competing with
other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
etc.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/20/22 17:03, Stephen Hoffman wrote:
> On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:
>
>> Why didn't ANSI fix some of the problems like null terminated strings,
>> requiring bounds checking, etc. when they had the chance?
>
> Just a guess: probably because the C committee is not entirely comprised
> of pendejos.
>
> While the C committee could make such changes, those changes would break
> enough existing C code that there'd be little reason not to break yet
> more of the existing C programs.

How would adding a string type break null terminated strings? One could
still use them but a safer option would be available. And then time and
inertia would eventually eliminate the bad practice. Bounds checking?
Even if it were to break something how would that be a bad idea as out
of bounds accesses are a really bad idea.

>
> Which then means this new C-family language would be competing with
> other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
> etc.

I guess I don't see how this would constitute a new language.
It would merely be a few minor tweaks to C but nothing would
actually change in the syntax or use of the language. And
the old ways would still be available. Heck you could even
make stuff like bounds checking an option in the compiler
but I really fail to see why anyone today would want to forego
it.

bill

On 5/20/2022 3:59 PM, Jake Hamby wrote:
> One VMSism that fascinates me is that it's the only OS that I've used
> with a calling standard that passes the number of arguments and their
> types (64-bit int or float) to the callee,

It certainly passes the number of arguments.

But type??

Arne

On Thursday, May 19, 2022 at 10:25:58 PM UTC-4, Craig A. Berry wrote:
> On 5/19/22 4:40 PM, Jake Hamby wrote:
> > On Thursday, May 19, 2022 at 10:50:44 AM UTC-7, Bill Gunshannon wrote:
> >> On 5/15/22 19:46, Arne Vajhøj wrote:
>
> >>> I would try and sell VMS as being lean. Linux is getting fat.
> >> Might work. Until the first time you have to run a benchmark.
>
> > That's a mean thing to say, but it's a big open question (at least
> > for me, since I don't have access to the x86 version): how well does VMS
> > actually perform on modern x86-64 hardware?
> It's going to remain an open question for some time. As far as I know,
> none of the cross compilers has optimizations turned on, which means
> there is no optimized code in the OS or libraries shipped with the OS,
> much less in anything you build yourself.
>
> Once the optimizations are available, you'll run into the inherently
> slow file I/O and network I/O that have been discussed many times here.
> The current roadmap does not include either of the new filesystems that
> have been planned and set aside, nor the networking overhaul (VCI 2.0).
> One can hope these will come back one day once the port to x86 is done.
>
> I would not expect VMS to be competitive in raw speed with other OSs on
> the same hardware anytime soon, but it really just needs to be a bit
> faster on virtual x86 than it was on the last generation of Integrity
> hardware for it to be a big step forward. Reducing cost and risk are
> going to be a lot more important to most people in the near term than
> increasing speed.
> > I've ported some simple IPC benchmarks from Linux to
> > find out for myself how well it performs on vintage hardware:
> >
> > https://github.com/jhamby/vms-ipc_benchmark/
> >
> > For comparison, running "pipe" and "tcp" with 8K message size, I can
> > easily get 6,500 MB/s, or 835,000 msg/s on an Intel Xeon W-1290P CPU @
> > 3.70GHz (turbo to 5.2 GHz) running Ubuntu 22.04 (kernel 5.15.0).
> >
> > On a dual 1.6 GHz / 3MB ("Fanwood") HP rx2620, the best I can get is
> > around 160MB/s, or 1/40 of the speed of the new PC. On my 667 MHz EV67
> > XP1000, I get about 65MB/s, or 1%. That hardware is from 2005 and 2002,
> > respectively. The Alpha hits a limit of around 20,000 msg/s that's a
> > bottleneck as I shrink the packet size to 4K and below, while the
> > Itanium handles smaller writes without much issue.
> > You'll also notice if you check the source code that I'm linking in
> > the vms_crtl_init.c and vms_crtl_values.c from the VSI Python 3.10 port,
> > which set the behavior of pipe() to be as UNIX-like as possible. Without
> > that, the speed would be hovering around 14MB/s on the Itanium.
> > Completely unacceptable.
> pipe() on VMS is based on mailboxes, an ancient virtual device
> technology that is convenient to use and quite effective for passing
> small messages around between processes. But it's slow, and it's a
> record-oriented device, which doesn't always play nice in a
> stream-oriented world (though stream-oriented behavior is emulated to
> some extent). For a faster pipe implementation see dmpipe, which uses
> global sections:
>
> https://sourceforge.net/p/vms-ports/dmpipe
>
> Unfortunately this involves wrapping pretty much every function in the
> CRTL that touches a file descriptor -- the fix should really be inside
> the CRTL, but, alas, that also is not on the roadmap.
I haven't forgotten about it. It isn't in yet as we've been focusing on other things
for the most recent ECOs.

On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
> On 5/20/2022 3:59 PM, Jake Hamby wrote:
> > One VMSism that fascinates me is that it's the only OS that I've used
> > with a calling standard that passes the number of arguments and their
> > types (64-bit int or float) to the callee,
> It certainly passes the number of arguments.
>
> But type??
>
> Arne
Only if you compile /TIE (which is not the default).

On Friday, May 20, 2022 at 4:28:26 PM UTC-4, jake....@gmail.com wrote:
> On Thursday, May 19, 2022 at 2:21:04 PM UTC-7, Jake Hamby wrote:
> > Nothing at all VMS-specific about that bug, and I really have had no complaints about DEC C/C++ in terms of the compiler crashing with internal errors or generating bad code or anything like that with open source programs I've compiled.
> I had to jinx myself: after I wrote that, I managed to get an internal compiler error in VSI C V7.4-002 on the Alpha by building rexx.exe with /PLUS_LIST_OPTIMIZE and /OPT=(LEV=5). I assume I managed to overflow some internal inlining logic. With level 4 optimization, the compile succeeds and the program is smaller and runs faster than with LEV=5 and no /PLUS_LIST.
>
> %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000000010, PC=00000000005F5F14, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> image module routine line rel PC abs PC
> DECC$COMPILER GEM_FI_PEEP MOVE_SECTION
> 5766 0000000000005604 00000000005F5F14
> DECC$COMPILER GEM_FI_PEEP REVERSE_CROSS_JUMP
> 7959 0000000000007A48 00000000005F8358
> DECC$COMPILER GEM_FI_PEEP GEM_FI_PEEP_BRANCH_PROCESSING
> 3075 000000000000217C 00000000005F2A8C
> DECC$COMPILER GEM_FI_PEEP_ALPHA GEM_FI_PEEP_APPLY_PEEPHOLE
> 741 0000000000000148 000000000083B168
> DECC$COMPILER GEM_FI_PEEP PROCESS_PATTERN_LIST
> 7573 0000000000007284 00000000005F7B94
> DECC$COMPILER GEM_FI_PEEP GEM_FI_PEEP
> 1579 00000000000003E4 00000000005F0CF4
> DECC$COMPILER 0 000000000049AC28 000000000049AC28
> DECC$COMPILER 0 000000000049B034 000000000049B034
> DECC$COMPILER GEM_CO GEM_CO_COMPILE_MODULE
> 3730 0000000000000D3C 000000000054EDEC
> DECC$COMPILER COMPILE gemc_be_master
> 93315 0000000000000F5C 00000000001C35BC
> DECC$COMPILER COMPILE 92535 00000000001C35BC 0000000000000000
> DECC$COMPILER GEM_CP_VMS GEM_CP_MAIN
> 2629 00000000000018BC 0000000000535AEC
> 0 FFFFFFFF80383C04 FFFFFFFF80383C04
> %TRACE-I-END, end of TRACE stack dump
> %MMK-F-ERRUPD, error status %X1000000C occurred when updating target REXX..EXE
/OPT=5 was always a work-in-progress when the Alpha work was stopped.
There was several places where it generated slower code than /OPT=4. That's
why 4 was left as the default.

On Friday, May 20, 2022 at 6:00:44 PM UTC-7, xyzz...@gmail.com wrote:
> /OPT=5 was always a work-in-progress when the Alpha work was stopped.
> There was several places where it generated slower code than /OPT=4. That's
> why 4 was left as the default.

That's good to know, thanks. On further inspection, the compiler ran out of heap memory. I watched it with ^T and it crashed after growing to around 1643 MB (210368 pages). /OPT=4 is perfectly fine for me.

I'd guess that there's had to have been some 64-bitification of the GEM compilers for x86-64 due to the size of compiling LLVM and Clang, if nothing else. I'm surprised that Microsoft Visual Studio has only been available as a 64-bit IDE for less than a year (Visual Studio 2022). They've been shipping x86-64 compilers for many years, but the compilers themselves have always been 32-bit until just now.

On Friday, May 20, 2022 at 5:58:40 PM UTC-7, xyzz...@gmail.com wrote:
> On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
> > On 5/20/2022 3:59 PM, Jake Hamby wrote:
> > > One VMSism that fascinates me is that it's the only OS that I've used
> > > with a calling standard that passes the number of arguments and their
> > > types (64-bit int or float) to the callee,
> > It certainly passes the number of arguments.
> >
> > But type??
> >
> > Arne
> Only if you compile /TIE (which is not the default).

Hmm, this seems to be a regression in x86-64 compared to Alpha and Itanium. VSI Calling Standard 3.6.1. Call Conventions:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32

See Figure 3.10. Argument Information Register (R25) Format. For Itanium, it's 4.7.5.3. Argument Information (AI) Register:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER

It's R25 in both cases. There are 8 x 3-bit fields in the register that indicate whether it's a 64-bit integer (or 32-bit sign extended), or one of the variety of floating-point formats supported. If this information is only being generated when compiled with /TIE, there's a serious omission in your own documentation.

On x86-64, the %rax register looks very different and indeed doesn't have the parameter type information:

https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARGUMENT_INFORMATION_REGISTER_X86_64

On 5/20/2022 6:26 PM, Bill Gunshannon wrote:
> On 5/20/22 17:03, Stephen Hoffman wrote:
>> On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:
>>
>>> Why didn't ANSI fix some of the problems like null terminated strings,
>>> requiring bounds checking, etc. when they had the chance?
>>
>> Just a guess: probably because the C committee is not entirely comprised of
>> pendejos.
>>
>> While the C committee could make such changes, those changes would break
>> enough existing C code that there'd be little reason not to break yet more of
>> the existing C programs.
>
> How would adding a string type break null terminated strings? One could
> still use them but a safer option would be available. And then time and
> inertia would eventually eliminate the bad practice. Bounds checking?
> Even if it were to break something how would that be a bad idea as out
> of bounds accesses are a really bad idea.
>
>>
>> Which then means this new C-family language would be competing with other
>> C-family languages; with the likes of Go, Rust, Swift, Zig, Java, etc.
>
> I guess I don't see how this would constitute a new language.
> It would merely be a few minor tweaks to C but nothing would
> actually change in the syntax or use of the language. And
> the old ways would still be available. Heck you could even
> make stuff like bounds checking an option in the compiler
> but I really fail to see why anyone today would want to forego
> it.
>
> bill
>

Do that, and someone like Simon will get in there and break some things.

:-)

--
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

On Friday, May 20, 2022 at 10:06:34 PM UTC-4, jake....@gmail.com wrote:
> On Friday, May 20, 2022 at 6:00:44 PM UTC-7, xyzz...@gmail.com wrote:
> > /OPT=5 was always a work-in-progress when the Alpha work was stopped.
> > There was several places where it generated slower code than /OPT=4. That's
> > why 4 was left as the default.
> That's good to know, thanks. On further inspection, the compiler ran out of heap memory. I watched it with ^T and it crashed after growing to around 1643 MB (210368 pages). /OPT=4 is perfectly fine for me.
>
> I'd guess that there's had to have been some 64-bitification of the GEM compilers for x86-64 due to the size of compiling LLVM and Clang, if nothing else. I'm surprised that Microsoft Visual Studio has only been available as a 64-bit IDE for less than a year (Visual Studio 2022). They've been shipping x86-64 compilers for many years, but the compilers themselves have always been 32-bit until just now.
The x86 cross-compilers are all 32-bit pointers including the LLVM pieces. For the native compilers, the frontends and GEM pieces are still 32-bit pointers. The GEM-to-LLVM is now 64-bit pointers and LLVM itself is compiled with 64-bit pointers.

On Friday, May 20, 2022 at 10:15:30 PM UTC-4, jake....@gmail.com wrote:
> On Friday, May 20, 2022 at 5:58:40 PM UTC-7, xyzz...@gmail.com wrote:
> > On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
> > > On 5/20/2022 3:59 PM, Jake Hamby wrote:
> > > > One VMSism that fascinates me is that it's the only OS that I've used
> > > > with a calling standard that passes the number of arguments and their
> > > > types (64-bit int or float) to the callee,
> > > It certainly passes the number of arguments.
> > >
> > > But type??
> > >
> > > Arne
> > Only if you compile /TIE (which is not the default).
> Hmm, this seems to be a regression in x86-64 compared to Alpha and Itanium. VSI Calling Standard 3.6.1. Call Conventions:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32
>
> See Figure 3.10. Argument Information Register (R25) Format. For Itanium, it's 4.7.5.3. Argument Information (AI) Register:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER
>
> It's R25 in both cases. There are 8 x 3-bit fields in the register that indicate whether it's a 64-bit integer (or 32-bit sign extended), or one of the variety of floating-point formats supported. If this information is only being generated when compiled with /TIE, there's a serious omission in your own documentation.
I'll double check. I might be thinking of the additional call signature relocations at external calls which might resolve to translated code.
>
> On x86-64, the %rax register looks very different and indeed doesn't have the parameter type information:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARGUMENT_INFORMATION_REGISTER_X86_64
Huh? There is the Argument Info Offset at at bit 47 and then CS talks about what the AIB looks like. We don't create them at this point. It is a latent definition.

On 2022-05-20 22:26:16 +0000, Bill Gunshannon said:

> On 5/20/22 17:03, Stephen Hoffman wrote:
>> On 2022-05-20 16:22:12 +0000, Bill Gunshannon said:
>>
>>> Why didn't ANSI fix some of the problems like null terminated strings,
>>> requiring bounds checking, etc. when they had the chance?
>>
>> Just a guess: probably because the C committee is not entirely
>> comprised of pendejos.
>>
>> While the C committee could make such changes, those changes would
>> break enough existing C code that there'd be little reason not to break
>> yet more of the existing C programs.
>
> How would adding a string type break null terminated strings?

Ah, okay. You were adding features, and not actually fixing things. I
got confused. My bad.

>> Which then means this new C-family language would be competing with
>> other C-family languages; with the likes of Go, Rust, Swift, Zig, Java,
>> etc.
>
> I guess I don't see how this would constitute a new language.

Objective C already provides this, and very nicely.

Or available with a migration to C++ for that matter, too.

But by all means, please do go design and create your new C language.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/20/22 7:30 PM, John Reagan wrote:
> On Thursday, May 19, 2022 at 10:25:58 PM UTC-4, Craig A. Berry wrote:
>> For a faster pipe implementation see dmpipe, which uses
>> global sections:
>>
>> https://sourceforge.net/p/vms-ports/dmpipe
>>
>> Unfortunately this involves wrapping pretty much every function in the
>> CRTL that touches a file descriptor -- the fix should really be inside
>> the CRTL, but, alas, that also is not on the roadmap.

> I haven't forgotten about it. It isn't in yet as we've been focusing on other things
> for the most recent ECOs.

Thanks, and I get it -- your priorities are where they need to be for now.

On Saturday, May 21, 2022 at 9:39:41 AM UTC-4, Craig A. Berry wrote:
> On 5/20/22 7:30 PM, John Reagan wrote:
> > On Thursday, May 19, 2022 at 10:25:58 PM UTC-4, Craig A. Berry wrote:
> >> For a faster pipe implementation see dmpipe, which uses
> >> global sections:
> >>
> >> https://sourceforge.net/p/vms-ports/dmpipe
> >>
> >> Unfortunately this involves wrapping pretty much every function in the
> >> CRTL that touches a file descriptor -- the fix should really be inside
> >> the CRTL, but, alas, that also is not on the roadmap.
>
> > I haven't forgotten about it. It isn't in yet as we've been focusing on other things
> > for the most recent ECOs.
> Thanks, and I get it -- your priorities are where they need to be for now.
I have asked for it to be moved up. Even with the PIPE driver (cousin of the
mailbox driver), I still see the record orientation showing up when I do something
like

$ pipe anal/obj/section=symbol | search sys$pipe symbolname

On 5/20/2022 10:15 PM, Jake Hamby wrote:
> On Friday, May 20, 2022 at 5:58:40 PM UTC-7, xyzz...@gmail.com wrote:
>> On Friday, May 20, 2022 at 7:46:43 PM UTC-4, Arne Vajhøj wrote:
>>> On 5/20/2022 3:59 PM, Jake Hamby wrote:
>>>> One VMSism that fascinates me is that it's the only OS that I've used
>>>> with a calling standard that passes the number of arguments and their
>>>> types (64-bit int or float) to the callee,
>>> It certainly passes the number of arguments.
>>>
>>> But type??

>> Only if you compile /TIE (which is not the default).
>
> Hmm, this seems to be a regression in x86-64 compared to Alpha and
> Itanium. VSI Calling Standard 3.6.1. Call Conventions:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#CALL_32
>
> See Figure 3.10. Argument Information Register (R25) Format. For
> Itanium, it's 4.7.5.3. Argument Information (AI) Register:
>
> https://docs.vmssoftware.com/vsi-openvms-calling-standard/#ARG_INFO_REGISTER
>
> It's R25 in both cases. There are 8 x 3-bit fields in the register
> that indicate whether it's a 64-bit integer (or 32-bit sign
> extended), or one of the variety of floating-point formats supported.
> If this information is only being generated when compiled with /TIE,
> there's a serious omission in your own documentation.
I had never seen that.

But I am not sure that I will call that passing type of argument.

It identifies arguments that are F, D, G, S and T floating point.

All the rest is bundled together: 8/16/32/64 bit integers, booleans,
string descriptors, arrays, structs etc.. It is passed in an
integer register, but it is not necessarily an integer.

Arne