In article <t2nklj$1vvk$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/07/22 20:17, Dan Cross wrote:
>> In article<jb8gsmF6ugqU1@mid.individual.net>,
>> Bill Gunshannon<bill.gunshannon@gmail.com> wrote:
>>> On 4/6/22 22:43, plugh wrote:
>>>>
>>>> Here's a car analogy: do you want to change a tire using a power tool or good ol' muscles?
>>>
>>> You better learn how to do it with "good ol' muscles" because
>>> when you get that flat at 2AM in the middle of nowhere there
>>> will be no power tool to do it for you.
>>
>> This is missing the point of the analogy.
>>
>> We're purporting ourselves to be professionals here, correct?
>> In a professional automotive shop, what's more likely: they've
>> got a set of professional-quality power tools for quickly
>> removing lug nuts, or they're out there with a wrench all the
>> time? Even in the cases where the power tool isn't appropriate
>> (or fails) a professional garage is going to have high quality
>> tools and know how to use them appropriate for the job at hand.
>>
>> Some poor slob changing a tire on the side of the road is more
>> analogous to an amateur or hobby programmer.
>
>I would prefer the simplest technology as backup, as that is
>less likely to fail than a more complex solution.

Note where I wrote, "Even in the cases where the power tool
isn't appropriate (or fails) a professional garage is going to
have high quality tools and know how to use them appropriate
for the job at hand."

>For wheel
>change, that means a manual jack, wheel brace or spanner
>and foot pump, which I always keep in the car.

Again, this misses the context. We're not talking about what
you keep in your car for the occasional flat tire. We're
talking about what a professional automotive shop uses on a
daily basis.

>Only needed
>once a flood anyway, so the simpler and more space saving
>the better. Must be the practical engineer in me, less is
>more etc...

But the "only needed once a flood anyway" case isn't the
interesting thing in this case. The analogy is related to tools
for professionals, not folks who have in the trunk for the very
rare occasional breakdown.

- Dan C.

In article <t2nmc0$kp7$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/07/22 19:59, Dan Cross wrote:
>> In article<t2n1o9$1fjb$1@gioia.aioe.org>,
>> chris<chris-nospam@tridac.net> wrote:
>>> On 04/07/22 15:59, Dan Cross wrote:
>>>> In article<t2l9jp$b8i$1@gioia.aioe.org>,
>>>> chris<chris-nospam@tridac.net> wrote:
>>>>> On 04/06/22 01:25, Dan Cross wrote:
>>>>> This sounds like medication to cure everyone from their sloppy
>>>>> programming. The infantilisation of complex subjects, just to give the
>>>>> lazy an easier time, while still getting the product built.
>>>>> The answer to that is not languages that constrain movement, but
>>>>> developing more professional skills and applying due diligence
>>>>> and attention to detail to system design and implementation.
>>>>>
>>>>> I must be getting old, so what happened to pursuit of excellence
>>>>> and more ?...
>>>>
>>>> Excellent practitioners curate their tools and select the ones
>>>> that give them the best chance of maximizing the effectiveness
>>>> of their work products. Ego driven machismo and disdain for
>>>> tooling that helps prevent defects is a sign of an amateurish
>>>> attitude towards software development, not that of a
>>>> professional, let alone an engineer.
>>>
>>> Agree 100% with that. Good engineers develop their own methods
>>> and tools as experience accumulates. Having said that, if you
>>> have been in the business for decades, you know what works and
>>> what doesn't and what is fluff, so a certain arrogance and
>>> intolerance of fools is normal. It's not an ego thing, but more
>>> often hard won experience in product delivery, often against
>>> the odds.
>>
>> That's funny. I've observed things changing significantly
>> across the industry in the last ~3 decades.
>
>and, point being ?. How is that relevant ot what I said ?.

I was responding to the culmination of three things that you
wrote:

"This sounds like medication to cure everyone from their sloppy
programming. The infantilisation of complex subjects, just to give the
lazy an easier time, while still getting the product built."

And then,

"[...] if you have been in the business for decades, you know
what works and what doesn't and what is fluff, so a certain
arrogance and intolerance of fools is normal."

And finally, an allusion to, "often hard won experience in
product delivery".

So in the first quote, you seem to be asserting that safer
languages are for the lazy who just don't want to put in the
work, while in the second, you refer to "what works and what
doesn't and what is fluff", but without acknowledging that new
techniques and tools are introduced all the time.

And finally you allude to your "hard won experience" while
simultaneously discounting others who disagree with you.

Taken together, this seems to indicate an attitude of, "if it
ain't broke, don't fix it" and aversion to incorporating change,
which seems strange. Truly, is the way you develop software
_now_ the same as how you developed software 25 years ago?

>> Entire new classes of problems that were once obscure research
>> domains have become the workaday domain of everyday programmers
>> (parallel programming, multithreading, distributed systems).
>> Interactivity has gone from terminals to graphical workstations
>> to web browsers. The unit of computing has gone from one CPU to
>> a multicore machine to a rack to a datacenter and beyond. We've
>> gone from "testing" being something lesser humans did to an
>> accepted practice performed by programmers and carried out in an
>> automated fashion.
>>
>> Distributed, scalable systems hosted in geographically dispersed
>> facilities, often pushed automatically by continuous integration
>> pipelines fed by distributed revision control repositories are
>> the new normal for tens of thousands of programmers across the
>> industry.
>
>Yes, oh, the complexity :-).
>
>> So yeah, keep what works (let's be honest: mostly techniques),
>> but if you're not also keeping up with the changes in technology
>> you're going to be left behind in an asymptotically shrinking
>> pool of legacy technology.
>
>Obviously, tech is a lifelong learning experience, always a
>student makes it very attractive. Take the best or useful
>ideas of the new, while maintaining core expertise in the
>current technology.

Yes, but the critical point is that the "current technology"
changes.

>In practice though, real time embedded
>work hasn't changed significantly in decades. Yes, we have more
>powerful processors, embedded linux and more, but the core
>techniques remain the same. No longer counting cycles in
>interrupt handlers on 6502, or writing complete systems in
>macro 11 asm (Yes, PDP11 was used extensively in oem real time
>embedded systems). All those older systems have been outclassed
>for years now, but the basic comp sci techniques developed back
>then can still be of value in the present.

Of course those techniques still have value, but no one ever
disputed that. But I disagree that things haven't changed, or
perhaps more precisely to the extent that they haven't that's a
bit of a problem.

See, for example, this:

http://cliffle.com/blog/on-hubris-and-humility/

>>> I don't apologise for that. Those who are not prepared to make
>>> the effort to learn their craft and accept substandard should
>>> not be in the business, no excuses...
>>
>> I think it's odd that people reject better tooling while they
>> assert that programmers should "make the effort to learn their
>> craft." Why are these things perceived as mutually exclusive?
>> Indeed, why isn't part of learning the "craft" adopting better
>> tooling? And who suggested accepting substandard results?
>>
>> On the other hand, those who stick their collective heads in the
>> sand and pretend that the same old techniques using the same old
>> tools in the same old way should consider leaving the business.
>
>There you are again, another dig at others suggest insecurity, but
>I digress. Fortunately, people like you don't get to decide who
>works in the business and who doesn't. That's decided by project
>managers and engineers who look for the right kind of experience
>and attitude for the work they are trying to get done...

You seem to be taking what I say rather personally. Perhaps
don't?

On the other hand, you write the following about those of us who
choose to use safer tools:

"This sounds like medication to cure everyone from their sloppy
programming. The infantilisation of complex subjects, just to give the
lazy an easier time, while still getting the product built."

Which is kind of hard to square with what you write above.

- Dan C.

In article <t2nn0k$rns$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>Far too much of an academic attitude.

Sounds like one of those "ad hominem on the sly" things you
were talking about.

>It's an imperfect world and
>in real life, systems get designed and built within the constraints
>of available tech of the day. Usually too much risk in working at
>the bleeding edge of tech, especially with unproven tools.

Static typing is not an "unproven tool".

- Dan C.

In article <624f803d$0$698$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/7/2022 12:27 PM, Dan Cross wrote:
>> In article <t2n2u6$3jv$1@gioia.aioe.org>,
>> chris <chris-nospam@tridac.net> wrote:
>>> The basic idea of a language as close as possible to the bare
>>> metal, yet with enough capability for serious high level work,
>>> with layered design, is as close to an ideal language as
>>> anyone could wish for. Tricky language indeed ?, rofl...
>>
>> The "C is close to the hardware" thing hasn't been true a long
>> time now.
>>
>> https://queue.acm.org/detail.cfm?id=3212479
>
>That is a rather unusual definition of close to HW.
>
>A way more common definition is that the language can
>actually directly access HW.
>
>Work with memory mapped devices etc.. And C typical
>does that great.

Does it, though? How well-defined are the semantics around, say
`volatile`?

>C pointers can for good or worse point anywhere.

Actually, they can't. For example, merely incrementing a
pointer that already points one-past the end of an array is UB.
(C11, sec 6.5.6, par 8). The mere existence of a pointer that
is improperly aligned for the type is UB (C11, sec 6.3.2.3,
par 7).

>Totally platform specific code,
>but it does it on Linux, Windows, VMS etc..
>Additionally close to HW may imply that not too
>much is happening under the hood.

I think that part of Chisnall's point is that the hardware is
actually doing a _lot_ of work under the hood to make C programs
fast. Register renaming, speculative and out-of-order execution
etc. None of that is visible to C.

- Dan C.

In article <t2o33a$18u$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>I was not discussing data or testing. I was discussing program design.

You were responding directly to a statement about the inherent
limitations of testing, and in that response you made the
statement:

"Not if all possible outcomes are expected and handled.

A good design will include handling all possible outcomes. Anything else is
just when, not if, something unexpected occurs."

Any reasonable reader could infer that was intended to discuss
testing, in which case the states in the program, as a function
of the data input to the program, are relevant.

- Dan C.

In article <624f89b3$0$694$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/7/2022 11:38 AM, Dan Cross wrote:
>> Have the likes of Robert
>> C Martin ever actually delivered a large program?
>
>He developed software in the Telecom business for
>many years before starting to focus on writing and
>training.

That doesn't actually answer my question. :-)

Most of his publicly available experience seems like it was more
in the development management space, less actually writing code.

Watching his (also very creepy) advent of code videos and seeing
what he has on github is pretty uninspiring about his actual
level of technical skill.

- Dan C.

On 4/8/2022 8:57 AM, Dan Cross wrote:
> In article <624f89b3$0$694$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/7/2022 11:38 AM, Dan Cross wrote:
>>> Have the likes of Robert
>>> C Martin ever actually delivered a large program?
>>
>> He developed software in the Telecom business for
>> many years before starting to focus on writing and
>> training.
>
> That doesn't actually answer my question. :-)
>
> Most of his publicly available experience seems like it was more
> in the development management space, less actually writing code.

There are not much detail available.

But I find it hard to believe that he walked directly from
his graduation to a managerial role in the 1970's telco world.

Arne

On 4/8/2022 8:45 AM, Dan Cross wrote:
> In article <624f803d$0$698$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/7/2022 12:27 PM, Dan Cross wrote:
>>> In article <t2n2u6$3jv$1@gioia.aioe.org>,
>>> chris <chris-nospam@tridac.net> wrote:
>>>> The basic idea of a language as close as possible to the bare
>>>> metal, yet with enough capability for serious high level work,
>>>> with layered design, is as close to an ideal language as
>>>> anyone could wish for. Tricky language indeed ?, rofl...
>>>
>>> The "C is close to the hardware" thing hasn't been true a long
>>> time now.
>>>
>>> https://queue.acm.org/detail.cfm?id=3212479
>>
>> That is a rather unusual definition of close to HW.
>>
>> A way more common definition is that the language can
>> actually directly access HW.
>>
>> Work with memory mapped devices etc.. And C typical
>> does that great.
>
> Does it, though? How well-defined are the semantics around, say
> `volatile`?
>
>> C pointers can for good or worse point anywhere.
>
> Actually, they can't. For example, merely incrementing a
> pointer that already points one-past the end of an array is UB.
> (C11, sec 6.5.6, par 8). The mere existence of a pointer that
> is improperly aligned for the type is UB (C11, sec 6.3.2.3,
> par 7).
>
>> Totally platform specific code,
>> but it does it on Linux, Windows, VMS etc..

You really should have read to the end.

There is a lot of compiler specific behavior in
such code.

But that doesn't matter. This sort of code is not
portable anyway.

You can write Linux drivers, Windows drivers and VMS
drivers in C. And people do so.

The code is very different on the platforms.

And the differences between GCC, MSVC++ and VMSC C
are not the main differences.

>> Additionally close to HW may imply that not too
>> much is happening under the hood.
>
> I think that part of Chisnall's point is that the hardware is
> actually doing a _lot_ of work under the hood to make C programs
> fast. Register renaming, speculative and out-of-order execution
> etc. None of that is visible to C.

It is not visible to any language. And because it may be
different between different implementation of the same
ISA, then it has to be invisible.

But I was talking about something different. That the
C code and the generated instructions sort of "match".

If you in C write:

c = a + b;

then you expect that it does an addition of
two pieces of data (integer or FP of some size
determined by declaration) and not anything else.

In languages with operator overload and extension methods
that code may download a bitcoin mining program and
run it for 10 minutes.

Arne

On 4/7/2022 2:22 PM, Simon Clubley wrote:
> On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2mkq4$ib9$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> The insane levels of promotion of Rust as "the" solution at the moment
>>> remind me of those days.
>>
>> I wonder where you are seeing that. Seriously. I know and/or
>> have worked with a number of members of the Rust community for
>> several years (members of the core, language, and tool teams,
>> for about 3 years), and they're quite gracious in admitting that
>> it's not the right solution for everything.
>
> That's nice to hear.
>
> As for where I am seeing it, it's more of a combined overall impression
> made up of gushing articles and what appears to be more like an organised
> religious cult (:-)) showing up at the usual places online.
>
> For example, articles that, instead of taking a balanced approach, spend
> the first 95% of the article saying how great and perfect Rust is, and only
> in the last 5% (if at all) start mentioning in passing the unsafe stuff
> "for when you really need to do that stuff".

There are all sorts of information available in the internet. Some
of it is correct information and written by people that know what they
are talking about. Some of it is totally BS written by people that
are totally clueless. And some is in between. That is the nature of the
modern internet.

To me the unsafe piece is really a key reason to use Rust.

If you want to write code that never need to do anything
dirty memory related then there are plenty of languages
to do so.

If you want to write code that always give you free hands
then continue with C or assembler or a few other.

If you want a language that does things safe 99% of places
but allow you do do unsafe things in selected 1% of places,
then the number of options become limited.

Rust is one of those very few options.

That automatically makes it a relevant language
for those writing such code.

And note that such code is only a small fraction
of all code - the vast majority of code is business
code without such needs.

And this is not just something I say now - if you
go back to my reply to Bill about why people should
look at Rust, then that was the message.

Disclaimer - I don't code in Rust. Which means that there
is a lot of details about Rust that I don't know, but it also
means that I do not really have any emotional connection
with the language.

Arne

On 4/7/2022 9:08 PM, Dave Froble wrote:
> On 4/7/2022 8:01 PM, Arne Vajhøj wrote:
>
>> Bad developers go for DIY methods and tools.
>
> Let me ask, just where do you think good methods and tools come from?

Good point.

Bad developers go for DIY methods and tools.

Ordinary good developers stand on the shoulders of giants.

Brilliant developers develop one or a few methods and tools
where they find a better way than what exist and stand on
shoulders of giants for the rest.

>> Good developers stand on the shoulders of giants.
>
> Where do you think the giants come from?
>
> Hint, it is NOT academia!

The original "If I have seen further it is by standing on the sholders
of Giants" was definitely about academia. But Newtons field was math
and physics not software development.

When it comes to software development some come from academia and
some from elsewhere (commercial, military, community).

Since the original topic was programming languages I picked 25
languages and checked:

Academic:

Lisp (MIT)
Basic (Dartmouth)
Algol (Zurich)
Pascal (Zurich)
C (Bell)
Modula-2 (Zurich)
C++ (Bell)
Python (CWI)
Scala (Lausanne)

Commercial:

Fortran (IBM)
Java (Sun)
JavaScript (NetScape)
C# (Microsoft)
Kotlin (Jetbrains)
Go (Google)
Dart (Ggogle)
Swift (Apple)
TypeScript (Microsoft)

Military:

Cobol
Ada

Community:

PHP
Ruby
Groovy
Rust

Arne

On 2022-04-08 15:33, Arne Vajhøj wrote:
> On 4/8/2022 8:45 AM, Dan Cross wrote:
>> In article <624f803d$0$698$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> Additionally close to HW may imply that not too
>>> much is happening under the hood.
>>
>> I think that part of Chisnall's point is that the hardware is
>> actually doing a _lot_ of work under the hood to make C programs
>> fast.  Register renaming, speculative and out-of-order execution
>> etc.  None of that is visible to C.
>
> It is not visible to any language. And because it may be
> different between different implementation of the same
> ISA, then it has to be invisible.

Sadly, it seems that people that profess to believe in C are not getting
what Dan is saying. While I actually like C, and do a lot of work in it,
Dan is absolutely right in that C have sortof silently failed lately.
With most people not realizing it.

> But I was talking about something different. That the
> C code and the generated instructions sort of "match".
>
> If you in C write:
>
> c = a + b;
>
> then you expect that it does an addition of
> two pieces of data (integer or FP of some size
> determined by declaration) and not anything else.
>
> In languages with operator overload and extension methods
> that code may download a bitcoin mining program and
> run it for 10 minutes.

Actually, you might get surprised about what C compilers might do with
this in some circumstances. If the size of the destination (c) is
smaller than a and/or b, and the compiler knows that the result is going
to be too large to fit, then you are again in UB. Which means the
compiler is allowed to do anything, including do nothing at all (even
though it might just be simple integer operations).
So that "c = a + b;" might actually end up being optimized away totally.
Which probably would surprise quite a number of people who wrote such a
line.

Or, as I had to explain to a colleague of mine at one point.
If you have two unsigned values multiplied, and the resulting value is
stored in a signed destination, any check for a value less than zero can
be optimzied away, because obviously the value can never be less than
zero. Disregarding the fact that the actual hardware, if giving such a
multiplication, might wrap, and end up with a value that is actually
less than zero.
The colleague had the test in his code, and it never triggered, but
printing the value out for sure showed that it was less than zero.

The compiler was technically allowed to do that optimization, since it's
UB. The writer of the code wanted to know if the value had wrapped.
Sorry, C does not actually allow you to find that out.

Took some examining of the resulting machine code before I realized what
the "problem" was.

Close to the hardware? Bah. You'll have to do silly stuff these days to
just get what the hardware actually is doing, since C compilers so
aggressively "abuse" UB.

Johnny

On 2022-04-08 14:45, Dan Cross wrote:
> In article <624f803d$0$698$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/7/2022 12:27 PM, Dan Cross wrote:
>>> In article <t2n2u6$3jv$1@gioia.aioe.org>,
>>> chris <chris-nospam@tridac.net> wrote:
>>>> The basic idea of a language as close as possible to the bare
>>>> metal, yet with enough capability for serious high level work,
>>>> with layered design, is as close to an ideal language as
>>>> anyone could wish for. Tricky language indeed ?, rofl...
>>>
>>> The "C is close to the hardware" thing hasn't been true a long
>>> time now.
>>>
>>> https://queue.acm.org/detail.cfm?id=3212479
>>
>> That is a rather unusual definition of close to HW.
>>
>> A way more common definition is that the language can
>> actually directly access HW.
>>
>> Work with memory mapped devices etc.. And C typical
>> does that great.
>
> Does it, though? How well-defined are the semantics around, say
> `volatile`?

volatile is simple enough. Every reference have to stay, and be kept in
the same order, and order also kept in relation to other volatile
variables, and the value cannot be "cached" or placed in a register, or
whatever. Memory barriers all around.

There are other parts that are much more devious in C these days.

>> C pointers can for good or worse point anywhere.
>
> Actually, they can't. For example, merely incrementing a
> pointer that already points one-past the end of an array is UB.
> (C11, sec 6.5.6, par 8). The mere existence of a pointer that
> is improperly aligned for the type is UB (C11, sec 6.3.2.3,
> par 7).

Yeah. That one is beautiful. (not)

>> Totally platform specific code,
>> but it does it on Linux, Windows, VMS etc..
>> Additionally close to HW may imply that not too
>> much is happening under the hood.
>
> I think that part of Chisnall's point is that the hardware is
> actually doing a _lot_ of work under the hood to make C programs
> fast. Register renaming, speculative and out-of-order execution
> etc. None of that is visible to C.

I think that point is pretty pointless, though.
These kind of tricks are not visible to anyone, not even when you write
in assembler. And it's not about making C programs fast, but making any
code fast.

But C compilers are doing a lot of things under the hood to make C
programs fast, and a lot of it is things people might not expect.

Johnny

In article <62504527$0$706$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>Since the original topic was programming languages I picked 25
>languages and checked:
>
>Academic:
>
>Lisp (MIT)
>Basic (Dartmouth)
>Algol (Zurich)
>Pascal (Zurich)
>C (Bell)
>Modula-2 (Zurich)
>C++ (Bell)
>Python (CWI)
>Scala (Lausanne)
>
>Commercial:
>
>Fortran (IBM)
>Java (Sun)
>JavaScript (NetScape)
>C# (Microsoft)
>Kotlin (Jetbrains)
>Go (Google)

While true, this is a big of a misnomer. Go is the latest in a
series of languages designed around CSP as the fundamental
concurrency primitive; the other four were done by the same
people at Bell Labs.

I'm not sure I'd describe Bell Labs as an academic institution,
but it probably shares more characteristics with academia than
it does with "industry."

>Dart (Ggogle)
>Swift (Apple)
>TypeScript (Microsoft)
>
>Military:
>
>Cobol
>Ada

Ada came out a committee that was a mixture of public and
private sector members and academics. It's true it was formed
at the behest of the US DoD and targetting military applications
but I'm not sure I'd call its design "military".
http://archive.adaic.com/pol-hist/history/holwg-93/holwg-93.htm

Similarly with COBOL. It came out of CODASYL, which was again
joint industry/public sector, but not specifically military.

>Community:
>
>PHP
>Ruby
>Groovy
>Rust

Actually, Rust came from Mozilla.

- Dan C.

On 4/8/2022 12:13 PM, Johnny Billquist wrote:
> On 2022-04-08 15:33, Arne Vajhøj wrote:
>> But I was talking about something different. That the
>> C code and the generated instructions sort of "match".
>>
>> If you in C write:
>>
>> c = a + b;
>>
>> then you expect that it does an addition of
>> two pieces of data (integer or FP of some size
>> determined by declaration) and not anything else.
>>
>> In languages with operator overload and extension methods
>> that code may download a bitcoin mining program and
>> run it for 10 minutes.
>
> Actually, you might get surprised about what C compilers might do with
> this in some circumstances. If the size of the destination (c) is
> smaller than a and/or b, and the compiler knows that the result is going
> to be too large to fit, then you are again in UB. Which means the
> compiler is allowed to do anything, including do nothing at all (even
> though it might just be simple integer operations).
> So that "c = a + b;" might actually end up being optimized away totally.
> Which probably would surprise quite a number of people who wrote such a
> line.
>
> Or, as I had to explain to a colleague of mine at one point.
> If you have two unsigned values multiplied, and the resulting value is
> stored in a signed destination, any check for a value less than zero can
> be optimzied away, because obviously the value can never be less than
> zero. Disregarding the fact that the actual hardware, if giving such a
> multiplication, might wrap, and end up with a value that is actually
> less than zero.
> The colleague had the test in his code, and it never triggered, but
> printing the value out for sure showed that it was less than zero.
>
> The compiler was technically allowed to do that optimization, since it's
> UB. The writer of the code wanted to know if the value had wrapped.
> Sorry, C does not actually allow you to find that out.

Yes.

But my point was not about something being optimized away
but about too much happening under the hood.

Arne

On 4/7/2022 9:01 AM, Bill Gunshannon wrote:
> On 4/6/22 12:35, Arne Vajhøj wrote:
>> On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
>>> Let me re-word that.  40 years ago the problems were well known
>>> and documented.  A company created a C compiler and support package
>>> to fix it.  The industry rejected it because the cost (and I don't
>>> mean the purchase price!) was too high.
>>>
>>> It is interesting that very little of this made it into the C
>>> Standard which is when they could have fixed all of it.  And
>>> they can't use the backwards compatibility argument because
>>> there was no compatibility maintained between K&R and ANSI C.
>>
>> How much is known about why that product failed?
>
> Today, little more than memories.  I don't imagine Don French is
> still around to ask but when the subject was discussed more than
> 20 years ago the general understanding was that the overhead was
> much more than users were willing to put up with.  Another example
> of something ahead of its time. (Like the UCSD P-machine and the
> STVOS.)
>
>> I could have been the overhead. But I doubt it. Many languages
>> from that era did either check or had the option of enabling checks.
>
> And many did not.  COBOL never did precisely because of the overhead.
> (Not sure if it does it today.)  Fortran may have been weak in this
> respect as I can remember working on a lot of programs where the
> solution seemed to hint at bounds problems.  Pascal seemed to always
> have the option to turn all of it off.  I think the intent was to
> develop with it on and then turn it off for the performance value
> when ready for production. (Again remembering that production was
> never Wirth's purpose for the language!)

VMS Fortran, Pascal, Cobol and Basic all support /CHECK=[NO]BOUNDS.

It is default on in Pascal and Basic. Default off in Fortran and Cobol.

>> And today it would almost certainly not have been an issue. Most
>> languages check.
>
> And yet, C still doesn't even after ANSI got control of it.

It would probably be more difficult to implement in C/C++
due to their let us call it flexible approach to pointers.

It would break a lot of bad code that did not need to
exceed bounds but actually did.

It would require an unsafe { } construct to allow
to exceed bounds where actually needed.

Too complicated and breaking too much existing
code. I am not surprised that it did not happen.

New languages have the benefit of starting without
luggage of backwards compatibility requirements.

Arne

On 4/7/2022 2:46 PM, Dan Cross wrote:
> In article <t2navi$sdf$2@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> BTW, I wouldn't mind seeing Ada's ranged integers showing up elsewhere,
>> including being supported as an array index. That's a very nice feature
>> of Ada.
>
> That's a feature I would very much like to have.

Pascal has it.

:-)

$ type ar.pas
program ar(input,output);

type
r = 1..3;
a = array[r] of integer;

var
v : a;
i : r;

begin
for i := 1 to 3 do begin
v[i] := 10 * i;
end;
writeln(v[1], ' ', v[2], ' ', v[3])
end.
$ pas ar
$ link ar
$ run ar
10 20 30

Well - Pascal has the declaration and usage part - it is
not as type safe as Ada. In Ada terminology r is a subtype
not a type.

$ type ar2.pas
program ar2(input,output);

type
r = 1..3;
a = array[r] of integer;

var
v : a;
i : r;

begin
for i := 1 to 3 do begin
v[i] := 10 * i;
end;
i := 4;
v[i] := 40;
writeln(v[1], ' ', v[2], ' ', v[3], ' ', v[4])
end.
$ pas ar2
$ link ar2
$ run ar2
%PAS-F-ARRINDVAL, array index value is out of range
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
ar2 AR2 AR2 16 000000000000002C
000000000002002C
0 FFFFFFFF80340964
FFFFFFFF80340964
%TRACE-I-END, end of TRACE stack dump
$ pas/check=sub ar2
$ link ar2
$ run ar2
%PAS-F-SUBASGVAL, subrange assignment value is out of range
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
ar2 AR2 AR2 15 000000000000002C
000000000002002C
0 FFFFFFFF80340964
FFFFFFFF80340964
%TRACE-I-END, end of TRACE stack dump

Arne

On 4/8/22 13:01, Arne Vajhøj wrote:
> On 4/7/2022 9:01 AM, Bill Gunshannon wrote:
>> On 4/6/22 12:35, Arne Vajhøj wrote:
>>> On 4/6/2022 12:08 PM, Bill Gunshannon wrote:
>>>> Let me re-word that.  40 years ago the problems were well known
>>>> and documented.  A company created a C compiler and support package
>>>> to fix it.  The industry rejected it because the cost (and I don't
>>>> mean the purchase price!) was too high.
>>>>
>>>> It is interesting that very little of this made it into the C
>>>> Standard which is when they could have fixed all of it.  And
>>>> they can't use the backwards compatibility argument because
>>>> there was no compatibility maintained between K&R and ANSI C.
>>>
>>> How much is known about why that product failed?
>>
>> Today, little more than memories.  I don't imagine Don French is
>> still around to ask but when the subject was discussed more than
>> 20 years ago the general understanding was that the overhead was
>> much more than users were willing to put up with.  Another example
>> of something ahead of its time. (Like the UCSD P-machine and the
>> STVOS.)
>>
>>> I could have been the overhead. But I doubt it. Many languages
>>> from that era did either check or had the option of enabling checks.
>>
>> And many did not.  COBOL never did precisely because of the overhead.
>> (Not sure if it does it today.)  Fortran may have been weak in this
>> respect as I can remember working on a lot of programs where the
>> solution seemed to hint at bounds problems.  Pascal seemed to always
>> have the option to turn all of it off.  I think the intent was to
>> develop with it on and then turn it off for the performance value
>> when ready for production. (Again remembering that production was
>> never Wirth's purpose for the language!)
>
> VMS Fortran, Pascal, Cobol and Basic all support /CHECK=[NO]BOUNDS.
>
> It is default on in Pascal and Basic. Default off in Fortran and Cobol.
>
>>> And today it would almost certainly not have been an issue. Most
>>> languages check.
>>
>> And yet, C still doesn't even after ANSI got control of it.
>
> It would probably be more difficult to implement in C/C++
> due to their let us call it flexible approach to pointers.
>
> It would break a lot of bad code that did not need to
> exceed bounds but actually did.
>
> It would require an unsafe { } construct to allow
> to exceed bounds where actually needed.
>
> Too complicated and breaking too much existing
> code. I am not surprised that it did not happen.
>
> New languages have the benefit of starting without
> luggage of backwards compatibility requirements.

As I stated elsewhere, the change to ANSI C from K&R broke
everything. You can not compile K&R with an ANSI C Compiler
and vice versa. What better time to fix it all?

bill

On 4/8/2022 1:13 PM, Bill Gunshannon wrote:
> On 4/8/22 13:01, Arne Vajhøj wrote:
>> On 4/7/2022 9:01 AM, Bill Gunshannon wrote:
>>> On 4/6/22 12:35, Arne Vajhøj wrote:
>>>> And today it would almost certainly not have been an issue. Most
>>>> languages check.
>>>
>>> And yet, C still doesn't even after ANSI got control of it.
>>
>> It would probably be more difficult to implement in C/C++
>> due to their let us call it flexible approach to pointers.
>>
>> It would break a lot of bad code that did not need to
>> exceed bounds but actually did.
>>
>> It would require an unsafe { } construct to allow
>> to exceed bounds where actually needed.
>>
>> Too complicated and breaking too much existing
>> code. I am not surprised that it did not happen.
>>
>> New languages have the benefit of starting without
>> luggage of backwards compatibility requirements.
>
> As I stated elsewhere, the change to ANSI C from K&R broke
> everything.  You can not compile K&R with an ANSI C Compiler
> and vice versa.  What better time to fix it all?

Not everything.

But it would obviously have been a lot better to do it in
89 than in 99 or 11.

We would probably need to find someone that was actually
in the C WG for C89 to know if the question came up and
if it did why they decided not to change.

Arne

On 2022-04-07, Dave Froble <davef@tsoft-inc.com> wrote:
> On 4/7/2022 2:42 PM, Bill Gunshannon wrote:
>>
>> And I am sure everyone carries a battery powered impact wrench in their
>> Tesla.
>>
>
> I cannot speak for "everyone", and it's not my fault some are not prepared.
> Some of us carry a decent emergency kit in our vehicles.
>

And some of us do the same when we go out walking.

It's weight I am very willing to carry. Just in case.

Some people like to be prepared. Some people find out the hard way
they _should_ have been prepared.

And then there are people like this:

https://www.bbc.co.uk/news/uk-wales-58283816

It's not the queues in that story I find amazing.

It's going up a mountain in flip-flops.

Simon.

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

On 4/8/2022 8:53 AM, Dan Cross wrote:
> In article <t2o33a$18u$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> I was not discussing data or testing. I was discussing program design.
>
> You were responding directly to a statement about the inherent
> limitations of testing, and in that response you made the
> statement:
>
> "Not if all possible outcomes are expected and handled.
>
> A good design will include handling all possible outcomes. Anything else is
> just when, not if, something unexpected occurs."
>
> Any reasonable reader could infer that was intended to discuss
> testing, in which case the states in the program, as a function
> of the data input to the program, are relevant.
>
> - Dan C.
>

Sorry if I got confused ...

--
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 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t2na4b$sdf$1@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> I wonder where you are seeing that. Seriously. I know and/or
>>> have worked with a number of members of the Rust community for
>>> several years (members of the core, language, and tool teams,
>>> for about 3 years), and they're quite gracious in admitting that
>>> it's not the right solution for everything.
>>
>>That's nice to hear.
>>
>>As for where I am seeing it, it's more of a combined overall impression
>>made up of gushing articles and what appears to be more like an organised
>>religious cult (:-)) showing up at the usual places online.
>>
>>For example, articles that, instead of taking a balanced approach, spend
>>the first 95% of the article saying how great and perfect Rust is, and only
>>in the last 5% (if at all) start mentioning in passing the unsafe stuff
>>"for when you really need to do that stuff".
>
> Could you perhaps provide a citation to one of these articles?
>

Interesting question. I obviously can't remember the locations of
the articles I found in the past, so I looked at a small sample of
articles returned by Google to see if I had problems with them.

Comments below.

https://dev.to/katholder/pros-and-cons-of-rust-language-313i

Obviously a gushing user type writeup with non of the serious
analysis and flaws such as unsafe code you would expect to see.

https://codilime.com/blog/why-is-rust-programming-language-so-popular/

Mentions briefly unsafe mode but doesn't make it clear that you can
invalidate _all_ the unique features and guarantees in Rust when you
use it. It makes it sound like it's some obscure thing that only affects
writing to memory like in C or C++. It also has this little gem:

|Rust's dual-mode model is one of its biggest advantages. In C++, on the
|other hand, you never know you've written unsafe code until somewhere down
|the line your software crashes or a security breach rears up.

Seriously ? In Rust unsafe mode, you have the same problem and C++ has
a number of features that allow programmers to build more robust self
checking code (although I wish, for example, [] was bounds checked and
that it wasn't delegated to .at() to enforce bounds checking. at() would
have been better as the unchecked version so you had to make a positive
decision to do that).

https://www.infoworld.com/article/3218074/what-is-rust-safe-fast-and-easy-software-development.html

Based on the complete bypassing of Rust's unique features seen in the
CVEs when running in unsafe mode, the following is either wrong or at
least misleading depending on how you look at it:

|Rust lets you live dangerously if you need to, to a point. Rust's safeties
|can be partly suspended where you need to manipulate memory directly, such
|as dereferencing a raw pointer a la C/C++. The key word is partly, because
|Rust's memory safety operations can never be completely disabled. Even
|then, you almost never have to take off the seatbelts for common use cases,
|so the end result is software that's safer by default.

Can never be fully disabled ? There are a set of CVEs that say otherwise.

BTW, in a related article at that site, the following Rust CVE was
disclosed:

https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html

Not the first time I have seen that type of mistake elsewhere. Interesting
that Rust can have the same problem and that it wasn't detected until now.

Simon.

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

On 4/8/2022 3:20 PM, Simon Clubley wrote:
> On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2na4b$sdf$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2022-04-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>>> I wonder where you are seeing that. Seriously. I know and/or
>>>> have worked with a number of members of the Rust community for
>>>> several years (members of the core, language, and tool teams,
>>>> for about 3 years), and they're quite gracious in admitting that
>>>> it's not the right solution for everything.
>>>
>>> That's nice to hear.
>>>
>>> As for where I am seeing it, it's more of a combined overall impression
>>> made up of gushing articles and what appears to be more like an organised
>>> religious cult (:-)) showing up at the usual places online.
>>>
>>> For example, articles that, instead of taking a balanced approach, spend
>>> the first 95% of the article saying how great and perfect Rust is, and only
>>> in the last 5% (if at all) start mentioning in passing the unsafe stuff
>>> "for when you really need to do that stuff".
>>
>> Could you perhaps provide a citation to one of these articles?
>>
>
> Interesting question. I obviously can't remember the locations of
> the articles I found in the past, so I looked at a small sample of
> articles returned by Google to see if I had problems with them.
>
> Comments below.
>
> https://dev.to/katholder/pros-and-cons-of-rust-language-313i
>
> Obviously a gushing user type writeup with non of the serious
> analysis and flaws such as unsafe code you would expect to see.

That article is pretty bad. 99% filler.

> https://codilime.com/blog/why-is-rust-programming-language-so-popular/
>
> Mentions briefly unsafe mode

There are 3 sections about it.

> but doesn't make it clear that you can
> invalidate _all_ the unique features and guarantees in Rust when you
> use it.

It doesn't because that is not the case.

It disable some features but not all - among other things it does
not disable memory ownership.

> It makes it sound like it's some obscure thing that only affects
> writing to memory like in C or C++. It also has this little gem:
>
> |Rust's dual-mode model is one of its biggest advantages. In C++, on the
> |other hand, you never know you've written unsafe code until somewhere down
> |the line your software crashes or a security breach rears up.
>
> Seriously ?

Yes. The 99% safe and 1% unsafe is exactly what makes the case for Rust.

> In Rust unsafe mode, you have the same problem

Yes. But you have limited where it happens.

> and C++ has
> a number of features that allow programmers to build more robust self
> checking code

All languages got that. But there is a big difference between
something enforced by language and compiler and something the language
allows the programmer to by following best practice.

> Based on the complete bypassing of Rust's unique features seen in the
> CVEs when running in unsafe mode,

Your assumption about unsafe bypassing everything is simply wrong.

> the following is either wrong or at
> least misleading depending on how you look at it:
>
> |Rust lets you live dangerously if you need to, to a point. Rust's safeties
> |can be partly suspended where you need to manipulate memory directly, such
> |as dereferencing a raw pointer a la C/C++. The key word is partly, because
> |Rust's memory safety operations can never be completely disabled. Even
> |then, you almost never have to take off the seatbelts for common use cases,
> |so the end result is software that's safer by default.
>
> Can never be fully disabled ? There are a set of CVEs that say otherwise.

No.

Some memory safety can be disabled by unsafe. And the CVE's are
example of that.

The CVE does not show all memory safety disabled.

That is your imagination.

> BTW, in a related article at that site, the following Rust CVE was
> disclosed:
>
> https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html
>
> Not the first time I have seen that type of mistake elsewhere. Interesting
> that Rust can have the same problem and that it wasn't detected until now.

There are still plenty of opportunities for problems in Rust.

Arne

On 4/8/22 13:23, Arne Vajhøj wrote:
> On 4/8/2022 1:13 PM, Bill Gunshannon wrote:
>> On 4/8/22 13:01, Arne Vajhøj wrote:
>>> On 4/7/2022 9:01 AM, Bill Gunshannon wrote:
>>>> On 4/6/22 12:35, Arne Vajhøj wrote:
>>>>> And today it would almost certainly not have been an issue. Most
>>>>> languages check.
>>>>
>>>> And yet, C still doesn't even after ANSI got control of it.
>>>
>>> It would probably be more difficult to implement in C/C++
>>> due to their let us call it flexible approach to pointers.
>>>
>>> It would break a lot of bad code that did not need to
>>> exceed bounds but actually did.
>>>
>>> It would require an unsafe { } construct to allow
>>> to exceed bounds where actually needed.
>>>
>>> Too complicated and breaking too much existing
>>> code. I am not surprised that it did not happen.
>>>
>>> New languages have the benefit of starting without
>>> luggage of backwards compatibility requirements.
>>
>> As I stated elsewhere, the change to ANSI C from K&R broke
>> everything.  You can not compile K&R with an ANSI C Compiler
>> and vice versa.  What better time to fix it all?
>
> Not everything.

If you can't compile K&R with an ANSI C compiler and you can't
compile ANSI C with a K&R compiler what exactly didn't get broken?

>
> But it would obviously have been a lot better to do it in
> 89 than in 99 or 11.
>
> We would probably need to find someone that was actually
> in the C WG for C89 to know if the question came up and
> if it did why they decided not to change.

That would make for an interesting conversation.

bill

On 4/8/2022 4:12 PM, Bill Gunshannon wrote:
> On 4/8/22 13:23, Arne Vajhøj wrote:
>> On 4/8/2022 1:13 PM, Bill Gunshannon wrote:
>>> As I stated elsewhere, the change to ANSI C from K&R broke
>>> everything.  You can not compile K&R with an ANSI C Compiler
>>> and vice versa.  What better time to fix it all?
>>
>> Not everything.
>
> If you can't compile K&R with an ANSI C compiler and you can't
> compile ANSI C with a K&R compiler what exactly didn't get broken?

I believe the breaking change was the function prototyping.

Which obviously have broad impact. But are also rather
trivial. I would assume plenty of conversion tools were
created.

Arne

On 4/7/2022 8:18 AM, Simon Clubley wrote:
> I don't know how old you are Dan, but I'm old enough to have gone
> through the early years of Java and the insane levels of hype that
> were being generated about Java during those days before things
> settled down and much of it _was_ revealed to be hype.

There were a lot of hype around Java in the late 90's and
very early 00's.

But seen in today's perspective it seems that even the most
optimistic Java enthusiasts back then seriously underestimated
the impact of Java.

Sure it was just another OO language and even though WORA
was nice, then it was not really kicking ass. And many
of the early Java technologies (applets, midlets,
EJB 1.x/2.x etc.) died quickly.

But it became extremely widely used. And most other
languages invented after it (in that market segment) has
been designed to be "a better Java".

And it pulled a lot of new concepts into mainstream
software development - the concepts were not necessarily
invented in the Java world, but the Java world
was where they had their first success driving their
adaptation elsewhere:

focus on interface inheritance over implementation inheritance
reflection
garbage collection
JIT compilation
ORM (entity beans with CMP)
logging frameworks (log4j)
unit testing (JUnit)
etc.

Arne