On 5/17/22 07:16, chris wrote:
> On 05/16/22 20:49, Arne Vajhøj wrote:
>> On 5/16/2022 3:27 PM, Stephen Hoffman wrote:
>>> On 2022-05-16 18:22:55 +0000, John Reagan said:
>>>> It is just another setting in the C frontend, so yes, it is there on
>>>> x86.  However, it hides SOOOO MANY errors and bad programming that I
>>>> strongly suggest people stop using it everywhere.
>>>
>>> If working with or updating old K&R C code, simply finding that
>>> compiler switch usually means added work remediating the issues
>>> reported by newer C compilers and newer C standards.
>>
>>> Fix the latent errors now, or troubleshoot in acceptance testing and
>>> production and find and fix a subset of the bugs later.
>>>
>>> Code refactoring and remediation is an ongoing and necessary project
>>> in all non-trivial code-bases, and finding K&R C code means it's been
>>> a while.
>>
>> I agree with the advice to get rid of any code requiring /STANDARD=VAXC.
>>
>> But I think those with the problem should consider whether
>> rewriting to standard C99 is the right choice or maybe go
>> for another language.
>>
>> If it is a device driver or similar then sure C is obvious.
>> But if it is a piece of business logic, then why should it
>> stay in C.
>>
>> Back in the mid-late 80's there were not that many
>> common alternatives and it was a period when some
>> people thought that C would take over the world and
>> everything should be written in C.
>>
>> Since then the number of languages has increased. And
>> many have realized that C is good for some things but
>> not good for a lot of other things.
>>
>> Maybe going C++ and a higher abstraction
>> level would make sense.
>>
>> Maybe going a lot higher and go for Java or
>> Python make sense.
>>
>> Maybe sticking to traditional procedural
>> but switching to Pascal or Basic make sense.
>>
>> Arne
>>
>>
>
> But most important of all, that sort of code refactoring needs
> people fluent in both the original and substitute languages.
> Since C is the most widely used language. might make sense to
> stick with it.
>
> Recipe for disaster to choose a substitute language which
> has a small available pool of programmers. Increases costs
> and risk of serious bugs...
>

Thank you. You beat me to it and said it more eloquently than I
would have.

bill

On 5/17/22 18:54, chris wrote:
> On 05/17/22 21:33, Arne Vajhøj wrote:
>> On 5/17/2022 7:16 AM, chris wrote:
>>> On 05/16/22 20:49, Arne Vajhøj wrote:
>>>> On 5/16/2022 3:27 PM, Stephen Hoffman wrote:
>>>>> On 2022-05-16 18:22:55 +0000, John Reagan said:
>>>>>> It is just another setting in the C frontend, so yes, it is there on
>>>>>> x86.  However, it hides SOOOO MANY errors and bad programming that I
>>>>>> strongly suggest people stop using it everywhere.
>>>>>
>>>>> If working with or updating old K&R C code, simply finding that
>>>>> compiler switch usually means added work remediating the issues
>>>>> reported by newer C compilers and newer C standards.
>>>>
>>>>> Fix the latent errors now, or troubleshoot in acceptance testing and
>>>>> production and find and fix a subset of the bugs later.
>>>>>
>>>>> Code refactoring and remediation is an ongoing and necessary project
>>>>> in all non-trivial code-bases, and finding K&R C code means it's been
>>>>> a while.
>>>>
>>>> I agree with the advice to get rid of any code requiring
>>>> /STANDARD=VAXC.
>>>>
>>>> But I think those with the problem should consider whether
>>>> rewriting to standard C99 is the right choice or maybe go
>>>> for another language.
>>>>
>>>> If it is a device driver or similar then sure C is obvious.
>>>> But if it is a piece of business logic, then why should it
>>>> stay in C.
>>>>
>>>> Back in the mid-late 80's there were not that many
>>>> common alternatives and it was a period when some
>>>> people thought that C would take over the world and
>>>> everything should be written in C.
>>>>
>>>> Since then the number of languages has increased. And
>>>> many have realized that C is good for some things but
>>>> not good for a lot of other things.
>>>>
>>>> Maybe going C++ and a higher abstraction
>>>> level would make sense.
>>>>
>>>> Maybe going a lot higher and go for Java or
>>>> Python make sense.
>>>>
>>>> Maybe sticking to traditional procedural
>>>> but switching to Pascal or Basic make sense.
>>>
>>> But most important of all, that sort of code refactoring needs
>>> people fluent in both the original and substitute languages.
>>
>> They need people able to read C and people able to write
>> in the new language.
>>
>>> Since C is the most widely used language. might make sense to
>>> stick with it.
>>  >
>>> Recipe for disaster to choose a substitute language which
>>> has a small available pool of programmers. Increases costs
>>> and risk of serious bugs...
>>
>> That could be a problem with Pascal and Basic.
>>
>> But you will find more Java and Python programmers than
>> C programmers today
>
> But are they software engineers ?. Different requirements
> apply, for example apps programming, web programming
> and embedded real time.

Sorry, based on what I saw in a place with a Masters Degree Program
in SE I would take a good old fashioned Programmer/Analyst over a
Software engineer any day.

>
>>
>> And probably around the same number of C++ programmers
>> as C programmers.
>>
>> And C is not really suited for the typical business
>> application - it was not created for such usage - and
>> it shows.
>>
>> Arne
>>
>
> No argument about that, but no doubt many business apps have
> been written in C in the past. C is still arguably the best
> systems programming language, despite fashions of the moment...

Actually, there is another one that was ideal but never found its
way into common usage or even off of one processor. PL/M.

bill

On 5/17/22 19:32, Arne Vajhøj wrote:
> On 5/17/2022 6:54 PM, chris wrote:
>> On 05/17/22 21:33, Arne Vajhøj wrote:
>>> On 5/17/2022 7:16 AM, chris wrote:
>>>> Since C is the most widely used language. might make sense to
>>>> stick with it.
>>>  >
>>>> Recipe for disaster to choose a substitute language which
>>>> has a small available pool of programmers. Increases costs
>>>> and risk of serious bugs...
>>>
>>> That could be a problem with Pascal and Basic.
>>>
>>> But you will find more Java and Python programmers than
>>> C programmers today
>>
>> But are they software engineers ?.
>
> Java and C++ programmers should have the same or maybe even
> higher percentage of sofware engineers as C programmers.
>
> Python probably a bit smaller due to the admin scripters
> and the data scientists.
>
>>                                     Different requirements
>> apply, for example apps programming, web programming
>> and embedded real time.
>
> Yes.
>
> But somewhere above - long dropped from quote - I was talking about
> business applications.

All the more reason I would shun Software Engineers in favor of
old fashioned Programmer/Analysts.

>
>>> And probably around the same number of C++ programmers
>>> as C programmers.
>>>
>>> And C is not really suited for the typical business
>>> application - it was not created for such usage - and
>>> it shows.
>>
>> No argument about that, but no doubt many business apps have
>> been written in C in the past. C is still arguably the best
>> systems programming language, despite fashions of the moment...
>
> C is definitely still king in this area.
>
> And going C for that is a safe choice.
>
> Rust, Go, Hare, Zig etc. are just "promising" but not
> "proven".

Promising what? Aren't they just solutions searching for a problem?
Or new ego trips.

bill

On 2022-05-19, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/16/22 15:27, Stephen Hoffman wrote:
>>
>>
>> If that remediation work doesn't happen, the new work inherently "owns"
>> the existing and quite possibly unstable K&R C code.
>>
>
> What makes the code inherently unstable just because it is K&R
> as opposed to the crap being written in the more modern languages?
>

Because of what the compilers let you get away with back then and
also didn't even bother to warn you about so you could realise there
was a problem and fix it.

These days, you get a lot more compiler errors and warnings and
code is better for it.

Have you forgotten about VAX C and what an improvement DEC C was ? :-)

Have you forgotten how bad your code is if you need to use /standard=vaxc
to compile it ? :-)

As John has just confirmed, that qualifier is still going to be
available for the GEM-based C compiler for x86-64...

Simon.

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

On 2022-05-19 17:55:12 +0000, Bill Gunshannon said:

> On 5/16/22 15:27, Stephen Hoffman wrote:
>>
>>
>> If that remediation work doesn't happen, the new work inherently "owns"
>> the existing and quite possibly unstable K&R C code.
>>
>
> What makes the code inherently unstable just because it is K&R as
> opposed to the crap being written in the more modern languages?

Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.

K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
adding code bugs, and that compilation usually also with YOLO-grade
diagnostics settings.

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.

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.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/19/22 14:10, Simon Clubley wrote:
> On 2022-05-19, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>
>>>
>>> If that remediation work doesn't happen, the new work inherently "owns"
>>> the existing and quite possibly unstable K&R C code.
>>>
>>
>> What makes the code inherently unstable just because it is K&R
>> as opposed to the crap being written in the more modern languages?
>>
>
> Because of what the compilers let you get away with back then and
> also didn't even bother to warn you about so you could realise there
> was a problem and fix it.

Are we talking compilers or language? No one is using PCC any more.

>
> These days, you get a lot more compiler errors and warnings and
> code is better for it.

And a modern compiler could not generate those warning for K&R?
Note, I said "could not" not doesn't.

>
> Have you forgotten about VAX C and what an improvement DEC C was ? :-)

And what does that have to do with the language? That's a compiler
issue.

>
> Have you forgotten how bad your code is if you need to use /standard=vaxc
> to compile it ? :-)

My code isn't bad. No matter what compiler I use or what compiler
options I choose. I don't rely on compilers to write my code.

>
> As John has just confirmed, that qualifier is still going to be
> available for the GEM-based C compiler for x86-64...

So? Do they deliberately allow bad code without even a warning
because "It's K&R"?

bill

On 5/19/22 15:11, Stephen Hoffman wrote:
> On 2022-05-19 17:55:12 +0000, Bill Gunshannon said:
>
>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>
>>>
>>> If that remediation work doesn't happen, the new work inherently
>>> "owns" the existing and quite possibly unstable K&R C code.
>>>
>>
>> What makes the code inherently unstable just because it is K&R as
>> opposed to the crap being written in the more modern languages?
>
> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>
> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
> adding code bugs, and that compilation usually also with YOLO-grade
> diagnostics settings.
>
> 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.
>
> 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.
>
>

But that's a compiler (or programmer) problem and has nothing to
do with K&R beyond the age of the language definition. A lot was
left out in the bygone era because of the limits on resources.
There is no reason, today, why th compiler can't point out the
bad ideas that programmers do that don't violate the K&R definition
but are just bad ideas. Do I need to point out the Safe C Compiler
again?

bill

On 2022-05-19 19:30:41 +0000, Bill Gunshannon said:

> On 5/19/22 15:11, Stephen Hoffman wrote:
>> On 2022-05-19 17:55:12 +0000, Bill Gunshannon said:
>>
>>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>>
>>>>
>>>> If that remediation work doesn't happen, the new work inherently "owns"
>>>> the existing and quite possibly unstable K&R C code.
>>>>
>>>
>>> What makes the code inherently unstable just because it is K&R as
>>> opposed to the crap being written in the more modern languages?
>>
>> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>>
>> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
>> adding code bugs, and that compilation usually also with YOLO-grade
>> diagnostics settings.
>>
>> 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.
>>
>> 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.
>>
>>
>
> But that's a compiler (or programmer) problem and has nothing to do
> with K&R beyond the age of the language definition. A lot was left out
> in the bygone era because of the limits on resources. There is no
> reason, today, why th compiler can't point out the bad ideas that
> programmers do that don't violate the K&R definition but are just bad
> ideas. Do I need to point out the Safe C Compiler again?

You're one of the most adorable folks here. That you continue to
contribute your wealth of knowledge and insight and experience is a
gift to all of us. And by all means, please do scope your projects and
price your project work however you want.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/19/2022 3:26 PM, Bill Gunshannon wrote:
> On 5/19/22 14:10, Simon Clubley wrote:
>> On 2022-05-19, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>>
>>>>
>>>> If that remediation work doesn't happen, the new work inherently "owns"
>>>> the existing and quite possibly unstable K&R C code.
>>>>
>>>
>>> What makes the code inherently unstable just because it is K&R
>>> as opposed to the crap being written in the more modern languages?
>>>
>>
>> Because of what the compilers let you get away with back then and
>> also didn't even bother to warn you about so you could realise there
>> was a problem and fix it.
>
> Are we talking compilers or language? No one is using PCC any more.
>
>>
>> These days, you get a lot more compiler errors and warnings and
>> code is better for it.
>
> And a modern compiler could not generate those warning for K&R?
> Note, I said "could not" not doesn't.
>
>>
>> Have you forgotten about VAX C and what an improvement DEC C was ? :-)
>
> And what does that have to do with the language? That's a compiler
> issue.
>
>>
>> Have you forgotten how bad your code is if you need to use /standard=vaxc
>> to compile it ? :-)
>
> My code isn't bad. No matter what compiler I use or what compiler
> options I choose. I don't rely on compilers to write my code.
>
>>
>> As John has just confirmed, that qualifier is still going to be
>> available for the GEM-based C compiler for x86-64...
>
> So? Do they deliberately allow bad code without even a warning
> because "It's K&R"?
>
> bill
>
>

My, Bill is kind of feisty these days. Wonder what they gave him in that
hospital? Have to get me some of that ...

:-)

--
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 Thursday, May 19, 2022 at 12:11:43 PM UTC-7, Stephen Hoffman wrote:
> > What makes the code inherently unstable just because it is K&R as
> > opposed to the crap being written in the more modern languages?
> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>
> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
> adding code bugs, and that compilation usually also with YOLO-grade
> diagnostics settings.
>
> 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.

I've been working on reviving the OpenVMS port of Regina (Rexx interpreter), which has been great fun (I have a strange sense of fun) and very educational. Before I could begin to tackle the VMS-specific wrapper functions (the previous author implemented nearly all of the DCL lexical functions as native Rexx functions, which I spent nearly a week modernizing), I had to fix compiler warnings produced by DEC C at the default warning level. Mismatched types (signed/unsigned, pointer types). Turning on the warnings you suggested has exposed a whole new set of questionable things to fix.

Apparently, few people are compiling Regina with the debug assertions enabled and running the test scripts that it comes with, because I spent some time worrying about an assertion failure in Regina's internal memory allocator, only to discover, fortunately, that it was a bug in their implementation of UPPER() and LOWER() that wasn't allocating a big enough string when the output string was longer than the input. 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.

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

-Jake

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:
> >
> > Linux got aio, epoll, libevent etc..
> >
> > Maybe it is more of a bolt-on than native, but it is there
> > and that is what matters.
> >
> > 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?

I don't think VSI did themselves any favors by demoing VMS booting up on a 9600 bps serial console or whatever speed they were using in VirtualBox. BTW, 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.

My biggest battle with tuning VMS was discovering that my BIOLM shouldn't be 10000 or higher, because then the writer seems to get congested and the CPU starts to idle and performance fluctuates. With a BIOLM of between 400 and 600, the sustained local pipe/socketpair/TCP/UDP performance (using MultiNet) are the numbers I reported.

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.

As I said, it's a big open question for me as to whether or not VMS actually *is* lean, because the hardware I have available to me as a hobbyist is so old.

Cheers,
Jake

In article <5e165e6b-c0c6-4dab-a2b6-f24c3d885a29n@googlegroups.com>,
jake.hamby@gmail.com (Jake Hamby) wrote:

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

In the late 1990s, when I was new there, my employers were testing the
same software regularly on three different Alpha platforms: 32-bit VMS,
32-bit Windows NT, and 64-bit OSF/1 UNIX. As best I remember, the OSF was
fastest, with Windows and VMS being approximately similar.

Of course, the hardware has changed a lot since then.

John

On 5/19/2022 1:50 PM, Bill Gunshannon wrote:
> On 5/15/22 19:46, Arne Vajhøj wrote:
>> On 5/13/2022 10:15 PM, Jake Hamby wrote:
>>> My sales pitch for VMS is that the architecture is well-suited for
>>> server applications today because async I/O is now very fashionable
>>> (Node.js, C#, Rust, any language with lambdas), and $QIO is the core
>>> of OpenVMS (and Windows NT as well, since they copied the idea). If
>>> you're used to the UNIX world, then VMS is going to be alien and you
>>> won't see at first what benefits it could provide, but if you're
>>> thinking in terms of a stack like Node.js or Erlang or some of the
>>> open source that VSI is porting to VMS, then it could potentially be
>>> efficient, if the drivers are, because the core OS is very lean
>>> (designed for a slow VAX).
>>
>> Linux got aio, epoll, libevent etc..
>>
>> Maybe it is more of a bolt-on than native, but it is there
>> and that is what matters.
>>
>> 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.

Nobody pick OS based on benchmarks today.

Speed is not the issue. Software bugs and vulnerabilities are
the issue. More code means higher risk.

Arne

On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
> On 5/19/22 15:11, Stephen Hoffman wrote:
>> On 2022-05-19 17:55:12 +0000, Bill Gunshannon said:
>>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>> If that remediation work doesn't happen, the new work inherently
>>>> "owns" the existing and quite possibly unstable K&R C code.
>>>
>>> What makes the code inherently unstable just because it is K&R as
>>> opposed to the crap being written in the more modern languages?
>>
>> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>>
>> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
>> adding code bugs, and that compilation usually also with YOLO-grade
>> diagnostics settings.
>>
>> 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.
>>
>> 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.
>
> But that's a compiler (or programmer) problem and has nothing to
> do with K&R beyond the age of the language definition.  A lot was
> left out in the bygone era because of the limits on resources.
> There is no reason, today, why th compiler can't point out the
> bad ideas that programmers do that don't violate the K&R definition
> but are just bad ideas. Do I need to point out the Safe C Compiler
> again?

Many things are possible.

But are there any really good checking K&R compilers
available?

If not then the fact that one could be written is not
that useful.

Arne

On 5/19/22 17:04, Dave Froble wrote:
> On 5/19/2022 3:26 PM, Bill Gunshannon wrote:
>> On 5/19/22 14:10, Simon Clubley wrote:
>>> On 2022-05-19, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>>>
>>>>>
>>>>> If that remediation work doesn't happen, the new work inherently
>>>>> "owns"
>>>>> the existing and quite possibly unstable K&R C code.
>>>>>
>>>>
>>>> What makes the code inherently unstable just because it is K&R
>>>> as opposed to the crap being written in the more modern languages?
>>>>
>>>
>>> Because of what the compilers let you get away with back then and
>>> also didn't even bother to warn you about so you could realise there
>>> was a problem and fix it.
>>
>> Are we talking compilers or language?  No one is using PCC any more.
>>
>>>
>>> These days, you get a lot more compiler errors and warnings and
>>> code is better for it.
>>
>> And a modern compiler could not generate those warning for K&R?
>> Note, I said "could not" not doesn't.
>>
>>>
>>> Have you forgotten about VAX C and what an improvement DEC C was ? :-)
>>
>> And what does that have to do with the language?  That's a compiler
>> issue.
>>
>>>
>>> Have you forgotten how bad your code is if you need to use
>>> /standard=vaxc
>>> to compile it ? :-)
>>
>> My code isn't bad.  No matter what compiler I use or what compiler
>> options I choose.  I don't rely on compilers to write my code.
>>
>>>
>>> As John has just confirmed, that qualifier is still going to be
>>> available for the GEM-based C compiler for x86-64...
>>
>> So?  Do they deliberately allow bad code without even a warning
>> because "It's K&R"?
>>
>> bill
>>
>>
>
> My, Bill is kind of feisty these days.  Wonder what they gave him in
> that hospital?  Have to get me some of that ...
>
> :-)
>

Trust me, no you don't. The only good news I got was that I
don't have COVID. Went in for knee surgery. Got to the OR.
Everybody jumped up and yelled "April Fool". Got a free ride
to the ER and 3 fun filled days in the hospital. Not a fun week.

bill

On 5/19/2022 2:05 PM, Bill Gunshannon wrote:
> On 5/17/22 19:32, Arne Vajhøj wrote:
>> On 5/17/2022 6:54 PM, chris wrote:
>>> On 05/17/22 21:33, Arne Vajhøj wrote:
>>>> And probably around the same number of C++ programmers
>>>> as C programmers.
>>>>
>>>> And C is not really suited for the typical business
>>>> application - it was not created for such usage - and
>>>> it shows.
>>>
>>> No argument about that, but no doubt many business apps have
>>> been written in C in the past. C is still arguably the best
>>> systems programming language, despite fashions of the moment...
>>
>> C is definitely still king in this area.
>>
>> And going C for that is a safe choice.
>>
>> Rust, Go, Hare, Zig etc. are just "promising" but not
>> "proven".
>
> Promising what?  Aren't they just solutions searching for a problem?
> Or new ego trips.

They all try to address some known problems in old languages.
The problems are identified and they fix them.

But that does not guarantee that they overall are better
than the old languages.

And in case there are multiple that are better it is
still open which one of the new languages is best.

Arne

On 5/19/22 21:12, Arne Vajhøj wrote:
> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>> On 5/19/22 15:11, Stephen Hoffman wrote:
>>> On 2022-05-19 17:55:12 +0000, Bill Gunshannon said:
>>>> On 5/16/22 15:27, Stephen Hoffman wrote:
>>>>> If that remediation work doesn't happen, the new work inherently
>>>>> "owns" the existing and quite possibly unstable K&R C code.
>>>>
>>>> What makes the code inherently unstable just because it is K&R as
>>>> opposed to the crap being written in the more modern languages?
>>>
>>> Undetected and unresolved latent bugs. Weird bugs. Irreproducible bugs.
>>>
>>> K&R C such as VAX C or DEC C with CC /STANDARD=VAXC is easy-mode for
>>> adding code bugs, and that compilation usually also with YOLO-grade
>>> diagnostics settings.
>>>
>>> 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.
>>>
>>> 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.
>>
>> But that's a compiler (or programmer) problem and has nothing to
>> do with K&R beyond the age of the language definition.  A lot was
>> left out in the bygone era because of the limits on resources.
>> There is no reason, today, why th compiler can't point out the
>> bad ideas that programmers do that don't violate the K&R definition
>> but are just bad ideas. Do I need to point out the Safe C Compiler
>> again?
>
> Many things are possible.
>
> But are there any really good checking K&R compilers
> available?

Yes, there was. I have mentioned it here numerous times. It
was called Safe C and was available on both the PDP-11 and VAX.
And, apparently, the industry resoundingly rejected it.

>
> If not then the fact that one could be written is not
> that useful.

Why is that? GCC was written from scratch. It was not a rehash
of PCC. They could have put anything they wanted into it. It
would seem they chose to put nothing new in it at all.

bill

On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
> On 5/19/22 21:12, Arne Vajhøj wrote:
>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>> But that's a compiler (or programmer) problem and has nothing to
>>> do with K&R beyond the age of the language definition.  A lot was
>>> left out in the bygone era because of the limits on resources.
>>> There is no reason, today, why th compiler can't point out the
>>> bad ideas that programmers do that don't violate the K&R definition
>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>> again?
>>
>> Many things are possible.
>>
>> But are there any really good checking K&R compilers
>> available?
>
> Yes, there was.  I have mentioned it here numerous times.  It
> was called Safe C and was available on both the PDP-11 and VAX.
> And, apparently, the industry resoundingly rejected it.

So there was something available 30-40 years ago.

That does not help anyone today.

>> If not then the fact that one could be written is not
>> that useful.
>
> Why is that?

Because those people with C code want to build their
C code - they do not want to write their own compiler.
They have to use the C compilers that are actual available
for the platforms of today.

Arne

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.

On 5/19/22 21:36, Arne Vajhøj wrote:
> On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
>> On 5/19/22 21:12, Arne Vajhøj wrote:
>>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>>> But that's a compiler (or programmer) problem and has nothing to
>>>> do with K&R beyond the age of the language definition.  A lot was
>>>> left out in the bygone era because of the limits on resources.
>>>> There is no reason, today, why th compiler can't point out the
>>>> bad ideas that programmers do that don't violate the K&R definition
>>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>>> again?
>>>
>>> Many things are possible.
>>>
>>> But are there any really good checking K&R compilers
>>> available?
>>
>> Yes, there was.  I have mentioned it here numerous times.  It
>> was called Safe C and was available on both the PDP-11 and VAX.
>> And, apparently, the industry resoundingly rejected it.
>
> So there was something available 30-40 years ago.
>
> That does not help anyone today.

Yes, but the point was that it could be. Just like they could
have come up with better string handling libraries which over
time could have found their way into the CRTL. Heck, ANSI
could have come up with a defined string that was not null
terminated. Over the past 30-40 years all of this could have
been done and with minimal impact on older code. A defined
string would not have stopped people from using a null
terminated array of char bujt it would have given an option
for future development and even maintenance of older programs.
But it wasn't and that is not the fault of the language.

>
>>> If not then the fact that one could be written is not
>>> that useful.
>>
>> Why is that?
>
> Because those people with C code want to build their
> C code - they do not want to write their own compiler.
> They have to use the C compilers that are actual available
> for the platforms of today.

No one had to write their own compiler. It was done. The
industry wasn't interested. For whatever reason they chose
to continue with compilers that allowed dangerous code. If
it had been accepted it could have been the new standard for
C compilers and we wouldn't be having this conversation. As
you said above, we had 30-40 years to fix this. We even had
a major change of the language by ANSI. Why did no one do
anything about it?

bill

On 5/20/2022 9:09 AM, Bill Gunshannon wrote:
> On 5/19/22 21:36, Arne Vajhøj wrote:
>> On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
>>> On 5/19/22 21:12, Arne Vajhøj wrote:
>>>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>>>> But that's a compiler (or programmer) problem and has nothing to
>>>>> do with K&R beyond the age of the language definition.  A lot was
>>>>> left out in the bygone era because of the limits on resources.
>>>>> There is no reason, today, why th compiler can't point out the
>>>>> bad ideas that programmers do that don't violate the K&R definition
>>>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>>>> again?
>>>>
>>>> Many things are possible.
>>>>
>>>> But are there any really good checking K&R compilers
>>>> available?
>>>
>>> Yes, there was.  I have mentioned it here numerous times.  It
>>> was called Safe C and was available on both the PDP-11 and VAX.
>>> And, apparently, the industry resoundingly rejected it.
>>
>> So there was something available 30-40 years ago.
>>
>> That does not help anyone today.
>
> Yes, but the point was that it could be.  Just like they could
> have come up with better string handling libraries which over
> time could have found their way into the CRTL.  Heck, ANSI
> could have come up with a defined string that was not null
> terminated.  Over the past 30-40 years all of this could have
> been done and with minimal impact on older code.  A defined
> string would not have stopped people from using a null
> terminated array of char bujt it would have given an option
> for future development and even maintenance of older programs.
> But it wasn't and that is not the fault of the language.
>
>>>> If not then the fact that one could be written is not
>>>> that useful.
>>>
>>> Why is that?
>>
>> Because those people with C code want to build their
>> C code - they do not want to write their own compiler.
>> They have to use the C compilers that are actual available
>> for the platforms of today.
>
> No one had to write their own compiler.  It was done.  The
> industry wasn't interested.  For whatever reason they chose
> to continue with compilers that allowed dangerous code.  If
> it had been accepted it could have been the new standard for
> C compilers and we wouldn't be having this conversation.  As
> you said above, we had 30-40 years to fix this.  We even had
> a major change of the language by ANSI.  Why did no one do
> anything about it?

A lot of things is possible. New compilers could be developed.
Some compiler existed 30-40 years ago.

But that does not help those with K&R C code today. They have
the compilers they have.

And based on how the state of world actually are today then
I think Hoff's advice made a lot of sense.

Arne

On 5/20/22 11:43, Arne Vajhøj wrote:
> On 5/20/2022 9:09 AM, Bill Gunshannon wrote:
>> On 5/19/22 21:36, Arne Vajhøj wrote:
>>> On 5/19/2022 9:31 PM, Bill Gunshannon wrote:
>>>> On 5/19/22 21:12, Arne Vajhøj wrote:
>>>>> On 5/19/2022 3:30 PM, Bill Gunshannon wrote:
>>>>>> But that's a compiler (or programmer) problem and has nothing to
>>>>>> do with K&R beyond the age of the language definition.  A lot was
>>>>>> left out in the bygone era because of the limits on resources.
>>>>>> There is no reason, today, why th compiler can't point out the
>>>>>> bad ideas that programmers do that don't violate the K&R definition
>>>>>> but are just bad ideas. Do I need to point out the Safe C Compiler
>>>>>> again?
>>>>>
>>>>> Many things are possible.
>>>>>
>>>>> But are there any really good checking K&R compilers
>>>>> available?
>>>>
>>>> Yes, there was.  I have mentioned it here numerous times.  It
>>>> was called Safe C and was available on both the PDP-11 and VAX.
>>>> And, apparently, the industry resoundingly rejected it.
>>>
>>> So there was something available 30-40 years ago.
>>>
>>> That does not help anyone today.
>>
>> Yes, but the point was that it could be.  Just like they could
>> have come up with better string handling libraries which over
>> time could have found their way into the CRTL.  Heck, ANSI
>> could have come up with a defined string that was not null
>> terminated.  Over the past 30-40 years all of this could have
>> been done and with minimal impact on older code.  A defined
>> string would not have stopped people from using a null
>> terminated array of char bujt it would have given an option
>> for future development and even maintenance of older programs.
>> But it wasn't and that is not the fault of the language.
>>
>>>>> If not then the fact that one could be written is not
>>>>> that useful.
>>>>
>>>> Why is that?
>>>
>>> Because those people with C code want to build their
>>> C code - they do not want to write their own compiler.
>>> They have to use the C compilers that are actual available
>>> for the platforms of today.
>>
>> No one had to write their own compiler.  It was done.  The
>> industry wasn't interested.  For whatever reason they chose
>> to continue with compilers that allowed dangerous code.  If
>> it had been accepted it could have been the new standard for
>> C compilers and we wouldn't be having this conversation.  As
>> you said above, we had 30-40 years to fix this.  We even had
>> a major change of the language by ANSI.  Why did no one do
>> anything about it?
>
> A lot of things is possible. New compilers could be developed.
> Some compiler existed 30-40 years ago.
>
> But that does not help those with K&R C code today. They have
> the compilers they have.
>
> And based on how the state of world actually are today then
> I think Hoff's advice made a lot of sense.

True, but some of what I mentioned isn't limited to compilers
or just K&R code.

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

bill

On Friday, May 20, 2022 at 9:22:17 AM UTC-7, Bill Gunshannon wrote:
> >
> > And based on how the state of world actually are today then
> > I think Hoff's advice made a lot of sense.
> True, but some of what I mentioned isn't limited to compilers
> or just K&R code.
>
> Why didn't ANSI fix some of the problems like null terminated
> strings, requiring bounds checking, etc. when they had the
> chance?
>
> bill

Well, C is very much in the "worse is better" spirit of software design that Richard Gabriel coined in 1989, to contrast with Lisp and other designs that focused on correctness rather than "move fast and break things".

C++ is the way it is because everyone wanted it to be backwards-compatible to C. It also didn't have the ability in the early days to support safer ways of working with data (STL, exceptions). If you want to see something truly hideous, look up how Symbian (EPOC32) implemented strings and byte buffers (ASCII and UTF-16) for an early GCC cross-compiler using their own custom class library (they had their own setjmp/longjmp based alternative to C++ exceptions, too).

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, so it's simple to implement variadic functions in C that don't crash if the programmer put too many "%" specifiers in their printf() string for the number of arguments passed. That's also how the CRTL can have POSIX functions with VMS extensions that take an extra argument or two. Without the argument info register, this wouldn't be possible, and isn't possible on UNIX or Windows.

In a fit of madness about 16 months ago, I started writing some C++ wrappers for VMS system primitives, string descriptors, RMS, etc. to see if it'd be possible to make a friendlier wrapper than the C API. One advantage of C++ is that it's possible to wrap classes around C in a zero-overhead way. In fact, some of my classes inherited from the VMS struct they add functions to.

https://github.com/jhamby/vms-cd-new/tree/main/src

Sadly, I didn't finish my C++ version of the "CD" utility I was trying to port from VAX MACRO, but the attempt was quite educational. I think the C APIs are sufficient for someone to wrap much higher-level abstractions on top of. If you look at VSI's Python modules for VMS system calls, you can see that they're very low-level wrappers on top of the VMS APIs, much like my C++ headers. I prefer the way the port of Regina works, where the author wrote implementations of the DCL F$ lexical functions and then does all the work under the hood in C code to get the info the user wants, as a string or integer.

Jake

On Thursday, May 19, 2022 at 7:25:58 PM UTC-7, Craig A. Berry wrote:
> 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 agree with everything you just said.

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

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.

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. So I'm going to have to revive the lib$spawn() based vms_do_command(), which uses mailbox devices, and was ironically #ifdef'd out later with the (too-optimistic) comment:

/*
* At least with OpenVMS 7.3-1 on Alpha, the Posix way seems to work.
* So there is no need to redirect on (now) bogus code.
* But I keep the code here in case I didn't see something.
*/

Honestly, I'm not sure what code paths any previous users of Regina on VMS were actually using, because, before I started making my changes, the do_command code was falling through to generic code that used temp files for redirection instead of any of the clever POSIX stuff that does mostly seem to work on VMS. It's just that I have to modify it to try to use lib$spawn() first, to achieve the original behavior of letting you put arbitrary DCL commands in Rexx scripts and redirect their input/output into files or Rexx FIFOs (a really cool feature of the language). The vfork()/execvp() code is still useful as a fallback, and when Regina needs to spawn itself as a subprocess.

Jake

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