On 2022-04-04, Dave Froble <davef@tsoft-inc.com> wrote:
> On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>> They could have introduced a compatibility mode. Let us call it
>> "DEC C approach".
>>
>> But they did not.
>>
>> Would difference decisions have been made if it had been an ISO
>> committee and not a BDFL?
>>
>> I don't know.
>
> I'm pretty sure that a committee of people already using the product would not
> allow a break such Python 2 to Python 3. That is the difference, and it is a
> major difference.
>
> Much as it pains me, I have to state that Simon is "right on" with this discussion.
>

$ set response/mode=good_natured

Oh, I bet it hurt you to say that... :-)

You know, a guy could actually got offended here. :-)

Simon.

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

On 2022-04-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t2g5jj$8kb$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>>On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>>> That people have old code bases that they build with old compilers or
>>> run with old interpreters is not Python specific. Lots of companies
>>> are buried in technical debt.
>>
>>Not "lots", but everyone.
>>
>>So often I see programmer types quite ready to change things. Those footing the
>>bill may not be so eager. In fact they are not. For the programmers, it is job
>>security, it is polishing their resume. Not good for anyone but the
>>programmers, and then they are not good for their employers.
>>
>>Off with their heads I say ...
>
> I strongly disagree. Technology evolves; over time, we learn
> about things that work well and we adopt those things, and we
> also learn about what does NOT work well, and let those things
> fall by the evolutionary wayside. This is good.
>

And in the real world, companies and organisations need to be able
to work on the existing codebase that they have invested significant
resources in without having to rewrite it every 2-3 years in a new
language or language variant as fashions change.

So, while they may be writing new stuff in a different way or with a
different language variant, they still need to be able to change an
existing codebase without throwing it away.

Are you purely a programmer writing new code (or code that you have been
assigned to work on), or you also responsible for making management
decisions about how to move an existing codebase forward into a new
environment or changing it in response to new requirements ?

Simon.

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

On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/4/2022 8:35 PM, Dan Cross wrote:
>> In article <t2fc4n$fml$3@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> But other languages are also evolving over time, and they do it in
>>> a way that guarantees the next language variant is just another
>>> language mode in the existing compilers. That means I know I can still
>>> compile code written to that old language variant in the years to come.
>>>
>>> If the Rust language isn't going through a formal language standards
>>> process, how do I know that I can compile existing Rust code in
>>> 5/10/20 years time ?
>
>> As for the, "how can I be sure my code will compile..." question
>> have a look at Rust "editions", that are per-crate attributes.
>> They provide exactly the sort of guarantees you are looking for.
>
> This thing:
>
> https://doc.rust-lang.org/edition-guide/editions/index.html
>
> ?
>
> It actually looks like Rust do prioritize compatibility.
>

Interesting. But it looks like there are limits with that approach:

|The requirement for crate interoperability implies some limits on the kinds
|of changes that we can make in an edition. In general, changes that occur
|in an edition tend to be "skin deep". All Rust code, regardless of edition,
|is ultimately compiled to the same internal representation within the
|compiler.

That looks like it wouldn't work so well if Rust decided to make major
internal functionality changes that couldn't compile to the same internal
representation.

Simon.

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

On 2022-04-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <jb2t2oF49voU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>So, I have been following this discussion for some time now. I have
>>never used Rust. I have never even looked at Rust. But I do have one
>>question.
>>
>>Just what is it that Rust can do that none of the already existing
>>languages could do?
>
> There are three main interacting features that are unique in
> their combination in the language that Rust brings to bear:
>
> 1) Lifetimes attached to pointers are a first-class primitive in
> the language. They are literally part of the type.
> References cannot outlive the objects they refer to.
> 2) A compile-time borrow checker that ensures that either a
> single mutable reference to an object, or one or more
> immutable references. In safe rust code, data races are
> impossible.
> 3) Object ownership is a first-class primitive in the language,
> and every object has exactly one owner. All objects must be
> initialized before use. Dangling pointers and uninitialized
> pointers are
>
> The combination of these things is incredibly powerful, and
> gives you type and memory safety _without garbage collection_.
> The result is that you program as if you were using a managed
> language, but with explicit control over memory allocation.
>
> You can even do this on bare metal. The langauge gives you a
> high degree of abstraction with the "core" library, even in
> kernel mode. In that context, it's actually quite pleasant to
> use.
>
> - Dan C.
>

Do you have any comments on the following Rust CVEs ?

It looks like Rust has come up with rather unique ways to screw up:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

Take this one (which I picked at random) for example:

https://rustsec.org/advisories/RUSTSEC-2020-0148.html

Or this one (which is a nice good old fashioned out of bounds memory access):

https://rustsec.org/advisories/RUSTSEC-2020-0039.html

How do they fit into what you say above ?

Simon.

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

In article <t2huv7$lpu$3@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2g5jj$8kb$1@dont-email.me>,
>> Dave Froble <davef@tsoft-inc.com> wrote:
>>>On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>>>> That people have old code bases that they build with old compilers or
>>>> run with old interpreters is not Python specific. Lots of companies
>>>> are buried in technical debt.
>>>
>>>Not "lots", but everyone.
>>>
>>>So often I see programmer types quite ready to change things. Those footing the
>>>bill may not be so eager. In fact they are not. For the programmers, it is job
>>>security, it is polishing their resume. Not good for anyone but the
>>>programmers, and then they are not good for their employers.
>>>
>>>Off with their heads I say ...
>>
>> I strongly disagree. Technology evolves; over time, we learn
>> about things that work well and we adopt those things, and we
>> also learn about what does NOT work well, and let those things
>> fall by the evolutionary wayside. This is good.
>
>And in the real world, companies and organisations need to be able
>to work on the existing codebase that they have invested significant
>resources in without having to rewrite it every 2-3 years in a new
>language or language variant as fashions change.

My experience has been that in the real world, people often
understand the need for strategic investment in technology, and
in particular, understand that modernization efforts are often a
sound investment.

That doesn't mean that we don't work with existing code bases.
Indeed, I'm working on a codebase right now that's been evolving
for 50 years through at least four commercial enterprises, a
huge number of universities, and now in an open source context.
Amazingly, illumos strives for compatibility with modern C
standards.

>So, while they may be writing new stuff in a different way or with a
>different language variant, they still need to be able to change an
>existing codebase without throwing it away.

Of course.

>Are you purely a programmer writing new code (or code that you have been
>assigned to work on), or you also responsible for making management
>decisions about how to move an existing codebase forward into a new
>environment or changing it in response to new requirements ?

Are you asking me, personally? I certainly hope you are not.
However, it is worth noting that a number of organizations know
how to evolve their codebases cleanly, over time, while
preserving their investment. Here's a great book full of good
lessons learned over 25 years at Google:
https://abseil.io/resources/swe-book

- Dan C.

In article <t2i0e4$lpu$5@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <jb2t2oF49voU1@mid.individual.net>,
>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>So, I have been following this discussion for some time now. I have
>>>never used Rust. I have never even looked at Rust. But I do have one
>>>question.
>>>
>>>Just what is it that Rust can do that none of the already existing
>>>languages could do?
>>
>> There are three main interacting features that are unique in
>> their combination in the language that Rust brings to bear:
>>
>> 1) Lifetimes attached to pointers are a first-class primitive in
>> the language. They are literally part of the type.
>> References cannot outlive the objects they refer to.
>> 2) A compile-time borrow checker that ensures that either a
>> single mutable reference to an object, or one or more
>> immutable references. In safe rust code, data races are
>> impossible.
>> 3) Object ownership is a first-class primitive in the language,
>> and every object has exactly one owner. All objects must be
>> initialized before use. Dangling pointers and uninitialized
>> pointers are
>>
>> The combination of these things is incredibly powerful, and
>> gives you type and memory safety _without garbage collection_.
>> The result is that you program as if you were using a managed
>> language, but with explicit control over memory allocation.
>>
>> You can even do this on bare metal. The langauge gives you a
>> high degree of abstraction with the "core" library, even in
>> kernel mode. In that context, it's actually quite pleasant to
>> use.
>
>Do you have any comments on the following Rust CVEs ?

Sure.

>It looks like Rust has come up with rather unique ways to screw up:
>
>https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

These mostly seem to be misuses of FFI interfaces, where the
bugs are the interface between Rust and foreign code, which is
necessarily unsafe.

Rust provides an "escape hatch" from some of the rules of the
language called, "unsafe" mode. In unsafe mode, you have access
to a superset of the language where you can do things you cannot
do in the safe subset (for example, one can dereference raw
pointers, or transmute between types). In unsafe code, the
burden to maintain the langauge's invariants shift from the
compiler to the programmer. What's interesting about this CVE
list is that that many of the bugs are in unsafe code.

>Take this one (which I picked at random) for example:
>
>https://rustsec.org/advisories/RUSTSEC-2020-0148.html

Hmm, that's a third-party package using unsafe code.

>Or this one (which is a nice good old fashioned out of bounds memory access):
>
>https://rustsec.org/advisories/RUSTSEC-2020-0039.html

That's a third-party package using unsafe code.

>How do they fit into what you say above ?

I don't think it has much to do with what I said above at all,
frankly. I never said that the language was a panacea that
prevents _all_ bugs. But it significantly raises the bar over
just about everything else out there.

But hey, don't take my word for it: why not try it out for
yourself? Write some example code and get a feel for it. The
Rust book is online and free (https://doc.rust-lang.org/book/)
(FD: one of the coauthors is a coworker), the toolchain is
readily available (https://rustup.rs/), and I think if you have
doubts about it you'll be arguing from a much stronger position
if you actually have some relevant experience.

- Dan C.

In article <t2hvn3$lpu$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-04, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> On 4/4/2022 8:35 PM, Dan Cross wrote:
>>> In article <t2fc4n$fml$3@dont-email.me>,
>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>> But other languages are also evolving over time, and they do it in
>>>> a way that guarantees the next language variant is just another
>>>> language mode in the existing compilers. That means I know I can still
>>>> compile code written to that old language variant in the years to come.
>>>>
>>>> If the Rust language isn't going through a formal language standards
>>>> process, how do I know that I can compile existing Rust code in
>>>> 5/10/20 years time ?
>>
>>> As for the, "how can I be sure my code will compile..." question
>>> have a look at Rust "editions", that are per-crate attributes.
>>> They provide exactly the sort of guarantees you are looking for.
>>
>> This thing:
>>
>> https://doc.rust-lang.org/edition-guide/editions/index.html
>>
>> ?
>>
>> It actually looks like Rust do prioritize compatibility.
>>
>
>Interesting. But it looks like there are limits with that approach:
>
>|The requirement for crate interoperability implies some limits on the kinds
>|of changes that we can make in an edition. In general, changes that occur
>|in an edition tend to be "skin deep". All Rust code, regardless of edition,
>|is ultimately compiled to the same internal representation within the
>|compiler.
>
>That looks like it wouldn't work so well if Rust decided to make major
>internal functionality changes that couldn't compile to the same internal
>representation.

Which is probably a pretty decent indication that they don't
intend to do that. You may find it instructive to read up on
the guarantees they make about "stable" language features; they
are actually quite conservative about what they stabilize.

A committee driven standards document (which, to reiterate yet
again, _will_ come) isn't a talisman against incompatibility.
Again, I bring up how pervasive use of UB in C means that
programs written 30 years ago to the then-current standard will
fail today when compiled with modern toolchains.

- Dan C.

On 4/5/22 15:04, Dan Cross wrote:
> In article <t2hvn3$lpu$4@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/4/2022 8:35 PM, Dan Cross wrote:
>>>> In article <t2fc4n$fml$3@dont-email.me>,
>>>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>>> But other languages are also evolving over time, and they do it in
>>>>> a way that guarantees the next language variant is just another
>>>>> language mode in the existing compilers. That means I know I can still
>>>>> compile code written to that old language variant in the years to come.
>>>>>
>>>>> If the Rust language isn't going through a formal language standards
>>>>> process, how do I know that I can compile existing Rust code in
>>>>> 5/10/20 years time ?
>>>
>>>> As for the, "how can I be sure my code will compile..." question
>>>> have a look at Rust "editions", that are per-crate attributes.
>>>> They provide exactly the sort of guarantees you are looking for.
>>>
>>> This thing:
>>>
>>> https://doc.rust-lang.org/edition-guide/editions/index.html
>>>
>>> ?
>>>
>>> It actually looks like Rust do prioritize compatibility.
>>>
>>
>> Interesting. But it looks like there are limits with that approach:
>>
>> |The requirement for crate interoperability implies some limits on the kinds
>> |of changes that we can make in an edition. In general, changes that occur
>> |in an edition tend to be "skin deep". All Rust code, regardless of edition,
>> |is ultimately compiled to the same internal representation within the
>> |compiler.
>>
>> That looks like it wouldn't work so well if Rust decided to make major
>> internal functionality changes that couldn't compile to the same internal
>> representation.
>
> Which is probably a pretty decent indication that they don't
> intend to do that. You may find it instructive to read up on
> the guarantees they make about "stable" language features; they
> are actually quite conservative about what they stabilize.
>
> A committee driven standards document (which, to reiterate yet
> again, _will_ come) isn't a talisman against incompatibility.
> Again, I bring up how pervasive use of UB in C means that
> programs written 30 years ago to the then-current standard will
> fail today when compiled with modern toolchains.

Maybe I'm just confused, but I don't see what time has to do with
anyone writing code relying on the results of UB. I would expect
there would be no guarantee of repeated results on the same hardware
using the same compiler and then running the program twice. Or am
I missing just what "UB" actually means here.

bill

On 4/5/22 14:55, Dan Cross wrote:
> In article <t2i0e4$lpu$5@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-04-05, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>> In article <jb2t2oF49voU1@mid.individual.net>,
>>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> So, I have been following this discussion for some time now. I have
>>>> never used Rust. I have never even looked at Rust. But I do have one
>>>> question.
>>>>
>>>> Just what is it that Rust can do that none of the already existing
>>>> languages could do?
>>>
>>> There are three main interacting features that are unique in
>>> their combination in the language that Rust brings to bear:
>>>
>>> 1) Lifetimes attached to pointers are a first-class primitive in
>>> the language. They are literally part of the type.
>>> References cannot outlive the objects they refer to.
>>> 2) A compile-time borrow checker that ensures that either a
>>> single mutable reference to an object, or one or more
>>> immutable references. In safe rust code, data races are
>>> impossible.
>>> 3) Object ownership is a first-class primitive in the language,
>>> and every object has exactly one owner. All objects must be
>>> initialized before use. Dangling pointers and uninitialized
>>> pointers are
>>>
>>> The combination of these things is incredibly powerful, and
>>> gives you type and memory safety _without garbage collection_.
>>> The result is that you program as if you were using a managed
>>> language, but with explicit control over memory allocation.
>>>
>>> You can even do this on bare metal. The langauge gives you a
>>> high degree of abstraction with the "core" library, even in
>>> kernel mode. In that context, it's actually quite pleasant to
>>> use.
>>
>> Do you have any comments on the following Rust CVEs ?
>
> Sure.
>
>> It looks like Rust has come up with rather unique ways to screw up:
>>
>> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
>
> These mostly seem to be misuses of FFI interfaces, where the
> bugs are the interface between Rust and foreign code, which is
> necessarily unsafe.
>
> Rust provides an "escape hatch" from some of the rules of the
> language called, "unsafe" mode. In unsafe mode, you have access
> to a superset of the language where you can do things you cannot
> do in the safe subset (for example, one can dereference raw
> pointers, or transmute between types). In unsafe code, the
> burden to maintain the langauge's invariants shift from the
> compiler to the programmer. What's interesting about this CVE
> list is that that many of the bugs are in unsafe code.
>
>> Take this one (which I picked at random) for example:
>>
>> https://rustsec.org/advisories/RUSTSEC-2020-0148.html
>
> Hmm, that's a third-party package using unsafe code.
>
>> Or this one (which is a nice good old fashioned out of bounds memory access):
>>
>> https://rustsec.org/advisories/RUSTSEC-2020-0039.html
>
> That's a third-party package using unsafe code.
>
>> How do they fit into what you say above ?
>
> I don't think it has much to do with what I said above at all,
> frankly. I never said that the language was a panacea that
> prevents _all_ bugs. But it significantly raises the bar over
> just about everything else out there.

And then provides a way to override all the safeties because sometimes
you just need to get the job done. By the way, for the few remaining
Ada advocates out there, Ada did the same thing with allowing safeties
to be turned off so you could write "unsafe" but functional code. So
did most versions of Pascal. C just doesn't make you turn the safeties
on and off.

bill

On 4/5/2022 1:30 PM, Simon Clubley wrote:
> On 2022-04-04, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 4/4/2022 2:37 PM, Arne Vajhøj wrote:
>>> They could have introduced a compatibility mode. Let us call it
>>> "DEC C approach".
>>>
>>> But they did not.
>>>
>>> Would difference decisions have been made if it had been an ISO
>>> committee and not a BDFL?
>>>
>>> I don't know.
>>
>> I'm pretty sure that a committee of people already using the product would not
>> allow a break such Python 2 to Python 3. That is the difference, and it is a
>> major difference.
>>
>> Much as it pains me, I have to state that Simon is "right on" with this discussion.
>>
>
> $ set response/mode=good_natured
>
> Oh, I bet it hurt you to say that... :-)

Oh, yes ...

> You know, a guy could actually got offended here. :-)

An adversarial relationship can expand your horizons and keep you on your toes.

See how helpful I am?

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

In article <jb3isvF8h79U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/5/22 15:04, Dan Cross wrote:
>> [snip]
>> A committee driven standards document (which, to reiterate yet
>> again, _will_ come) isn't a talisman against incompatibility.
>> Again, I bring up how pervasive use of UB in C means that
>> programs written 30 years ago to the then-current standard will
>> fail today when compiled with modern toolchains.
>
>Maybe I'm just confused, but I don't see what time has to do with
>anyone writing code relying on the results of UB. I would expect
>there would be no guarantee of repeated results on the same hardware
>using the same compiler and then running the program twice. Or am
>I missing just what "UB" actually means here.

Well, consider this code from sec 2.3 of the paper I linked earlier
(https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf):

01. int do_fallocate(..., loff_t offset, loff_t len)
02. {
03. struct inode *inode = ...;
04. if (offset < 0 || len <= 0)
05. return -EINVAL;
06. /* Check for wrap through zero too */
07. if ((offset + len > inode->i_sb->s_maxbytes)
08. || (offset + len < 0))
09. return -EFBIG;
10. ...
$n. }

(This code was originally taken from the Linux kernel)

As a result of the `if` statement on line 04, the compiler
"knows" that both `offset` and `len` are non-negative (indeed,
it even "knows" that `len` is positive! But I digress). But,
in C, signed integer overflow is UB, so the compiler is free to
assume that the condition on line 08 _cannot happen_. Thus, it
is free to elide that part of the condition in the `if` on 07,
simplifying the entire condition to,
`if (offset + len) > inode->i_sb->s_maxbytes) return -EFBIG;`.
That is, it can assume that `do_fallocate` is _always_ called
in such a way that `offset+len` _never_ overflows. But of
course, in the real world, that's just not true; something
_could_ call `do_fallocate` in such a way that `offset+len`
overflows.

The issue in production arose because a programmer relied on the
compiler not eliding the overflow check in the conditional; that
is, the code relied on the compilier ignoring the UB and doing
the right thing. I'd imagine that at the time the code was
written, this was probably true; but then a new version of the
compiler came along that included the elision as an optimization
and hilarity ensued.

The point is that, even though C has a standard, it is riddled
with almost inescapable UB, and compiler writers can, and WILL,
take advantage of that over time. New versions of compilers may
well introduce UB-based optimizations that fundamentally alter
the behavior and indeed the correctness of programs without the
programs themselves changing.

There is _tons_ of this floating around with respect to the
memory model, which wasn't even specified until C11, even though
we've been writing multithreaded C programs since the 70s (e.g.
the Unix kernel).

And UB is extraordinarily easy to trip over in C. For example,
consider this almost trivial function:

uint16_t
mul(uint16_t a, uint16_t b)
{ return a * b;
}

Is that well-defined? Sadly the answer is, "it depends, but
probably not." In particular, on a machine/toolchain where,
say, `int` is 32 bits wide and `uint16_t` is `unsigned short`,
the answer is "no." In particular, the "usual arithmetic
conversions" will be applied to the operands prior to the
multiplication operation; on a machine where `short` has lesser
"rank" than `int`, and the range of `uint16_t` is fully
expressible as a _signed_ integer, then the operands will
automatically be promoted to _signed_ ints prior to the
multiplication. Since there exist uint16_t's a and b such
that a*b is greater than the largest signed int, we're back in
UB land. So the compiler is free to assume it never happens;
how may that manifest itself in a real program? The compiler,
for whatever reason, may decide to use e.g. a saturating
multiplication instruction to implement the operation, which
would likely yield surprising results. Again, this is the sort
of landmine that may lay hidden in a codebase for _years_ until
a new, sufficiently aggressive compiler, steps on it.

Btw, this bit of code might be "fixed" by writing it as:

uint16_t
mul(uint16_t a, uint16_t b)
{ unsigned int aa = a;
unsigned int bb = b;
return aa * bb;
}

Thus, the multiplication will be performed as an _unsigned_
operation, which has well-defined overflow semantics, and the
truncation to the narrower type is similarly well defined.

In Rust, we'd write it as:

fn mul(a: u16, b: u16) -> u16 {
a.wrapping_mul(b)
}

In Rust, by default, _any_ overflow can panic the program, but
we can explicitly request modular arithmetic via `wrapping_mul`.

- Dan C.

On 4/5/22 15:59, Dan Cross wrote:
> In article <jb3isvF8h79U1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 4/5/22 15:04, Dan Cross wrote:
>>> [snip]
>>> A committee driven standards document (which, to reiterate yet
>>> again, _will_ come) isn't a talisman against incompatibility.
>>> Again, I bring up how pervasive use of UB in C means that
>>> programs written 30 years ago to the then-current standard will
>>> fail today when compiled with modern toolchains.
>>
>> Maybe I'm just confused, but I don't see what time has to do with
>> anyone writing code relying on the results of UB. I would expect
>> there would be no guarantee of repeated results on the same hardware
>> using the same compiler and then running the program twice. Or am
>> I missing just what "UB" actually means here.
>
> Well, consider this code from sec 2.3 of the paper I linked earlier
> (https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf):
>
> 01. int do_fallocate(..., loff_t offset, loff_t len)
> 02. {
> 03. struct inode *inode = ...;
> 04. if (offset < 0 || len <= 0)
> 05. return -EINVAL;
> 06. /* Check for wrap through zero too */
> 07. if ((offset + len > inode->i_sb->s_maxbytes)
> 08. || (offset + len < 0))
> 09. return -EFBIG;
> 10. ...
> $n. }
>
> (This code was originally taken from the Linux kernel)
>
> As a result of the `if` statement on line 04, the compiler
> "knows" that both `offset` and `len` are non-negative (indeed,
> it even "knows" that `len` is positive! But I digress). But,
> in C, signed integer overflow is UB, so the compiler is free to
> assume that the condition on line 08 _cannot happen_. Thus, it
> is free to elide that part of the condition in the `if` on 07,
> simplifying the entire condition to,
> `if (offset + len) > inode->i_sb->s_maxbytes) return -EFBIG;`.
> That is, it can assume that `do_fallocate` is _always_ called
> in such a way that `offset+len` _never_ overflows. But of
> course, in the real world, that's just not true; something
> _could_ call `do_fallocate` in such a way that `offset+len`
> overflows.
>
> The issue in production arose because a programmer relied on the
> compiler not eliding the overflow check in the conditional; that
> is, the code relied on the compilier ignoring the UB and doing
> the right thing. I'd imagine that at the time the code was
> written, this was probably true; but then a new version of the
> compiler came along that included the elision as an optimization
> and hilarity ensued.
>
> The point is that, even though C has a standard, it is riddled
> with almost inescapable UB, and compiler writers can, and WILL,
> take advantage of that over time. New versions of compilers may
> well introduce UB-based optimizations that fundamentally alter
> the behavior and indeed the correctness of programs without the
> programs themselves changing.

But, that was my point exactly. A definition of "UB" means that
particular case should never be used because the results are "UB".
Not the fault of the language. Not the fault of the compiler.
Strictly the fault of truly bad programmers.

>
> There is _tons_ of this floating around with respect to the
> memory model, which wasn't even specified until C11, even though
> we've been writing multithreaded C programs since the 70s (e.g.
> the Unix kernel).
>
> And UB is extraordinarily easy to trip over in C. For example,
> consider this almost trivial function:
>
> uint16_t
> mul(uint16_t a, uint16_t b)
> {
> return a * b;
> }

OK, I have to ask. "UB" means "undefined Behaviour", right?
Just so I know we are talking about the same thing here.

>
> Is that well-defined? Sadly the answer is, "it depends, but
> probably not." In particular, on a machine/toolchain where,
> say, `int` is 32 bits wide and `uint16_t` is `unsigned short`,
> the answer is "no." In particular, the "usual arithmetic
> conversions" will be applied to the operands prior to the
> multiplication operation; on a machine where `short` has lesser
> "rank" than `int`, and the range of `uint16_t` is fully
> expressible as a _signed_ integer, then the operands will
> automatically be promoted to _signed_ ints prior to the
> multiplication. Since there exist uint16_t's a and b such
> that a*b is greater than the largest signed int, we're back in
> UB land. So the compiler is free to assume it never happens;
> how may that manifest itself in a real program? The compiler,
> for whatever reason, may decide to use e.g. a saturating
> multiplication instruction to implement the operation, which
> would likely yield surprising results. Again, this is the sort
> of landmine that may lay hidden in a codebase for _years_ until
> a new, sufficiently aggressive compiler, steps on it.
>
> Btw, this bit of code might be "fixed" by writing it as:
>
> uint16_t
> mul(uint16_t a, uint16_t b)
> {
> unsigned int aa = a;
> unsigned int bb = b;
> return aa * bb;
> }
>
> Thus, the multiplication will be performed as an _unsigned_
> operation, which has well-defined overflow semantics, and the
> truncation to the narrower type is similarly well defined.

Exactly. A good programmer would have done it correctly and not
written it relying on UB. That's my point.

>
> In Rust, we'd write it as:
>
> fn mul(a: u16, b: u16) -> u16 {
> a.wrapping_mul(b)
> }
>
> In Rust, by default, _any_ overflow can panic the program, but
> we can explicitly request modular arithmetic via `wrapping_mul`.

Well, I don't know Rust so I really have no idea what that means.
But, once again, it looks like we are trying to create languages
who's intent is to stop programmers from shooting themselves in
the foot. A better idea would be teaching the programmer not to
shoot himself in the foot because if you rely on a language to do
it programmers will continue to shoot themselves in the foot.

bill

In article <jb3j5nF8k0uU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/5/22 14:55, Dan Cross wrote:
>> [snip]
>> I don't think it has much to do with what I said above at all,
>> frankly. I never said that the language was a panacea that
>> prevents _all_ bugs. But it significantly raises the bar over
>> just about everything else out there.
>
>And then provides a way to override all the safeties because sometimes
>you just need to get the job done. By the way, for the few remaining
>Ada advocates out there, Ada did the same thing with allowing safeties
>to be turned off so you could write "unsafe" but functional code. So
>did most versions of Pascal. C just doesn't make you turn the safeties
>on and off.

Yes, but you'd be surprised how often you can avoid it. I sure
was, coming from 25 years of C. Indeed, learning Rust made me a
better C programmer because it started forcing me to pay
attention to things that simply never rose to my attention in C.

C has no way to express much of the safety properties that Rust
can give you _at all_. Take ownership as a simple example;
often that is specified in comments. By contrast, in Rust, by
default an assignment for non-trivial types is a move, and once
you'ved moved a value out of a variable, using the variable
again is an error. Hence, ownership can be transferred in a way
that the compiler can track. For example:

struct Foo {
a: u32,
b: u32,
}

fn broken() {
let a = Foo { a: 0, b: 0 };
let r = &a;
// The following line is an error:
// we are trying to "move out of a"
// while a reference to a is still
// alive. Here, was say that
// "r outlives a."
let b = a;
println!("b.a = {}, b.b = {}", b.a, b.b);
println!("r.a = {}, r.b = {}", r.a, r.b);
}

Note that if we get rid of the second print, this will compile
(though we'll get a warning because we never use `r`), so the
language is smart enough to ignore a pointer that's not used
after the thing it points to goes away. If we simply move the
second print before the assignment to b, it'll just work
without diagnostics.

- Dan C.

In article <jb3mlhF98vlU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/5/22 15:59, Dan Cross wrote:
>> [snip]
>> The point is that, even though C has a standard, it is riddled
>> with almost inescapable UB, and compiler writers can, and WILL,
>> take advantage of that over time. New versions of compilers may
>> well introduce UB-based optimizations that fundamentally alter
>> the behavior and indeed the correctness of programs without the
>> programs themselves changing.
>
>But, that was my point exactly. A definition of "UB" means that
>particular case should never be used because the results are "UB".
>Not the fault of the language. Not the fault of the compiler.
>Strictly the fault of truly bad programmers.

Ah, so you think it's EASY to avoid UB in C. That's what a lot
of folks say, but it turns out that it's nearly impossible to do
so in a non-trivial codebase. That's because often the UB isn't
_in the source program_ but is emergent only after multiple
layers of translation and optimization have kicked in.

I used to sit down the hall from a bunch of folks who work on
LLVM and its C/C++ compilers; I once asked them, "why can't you
just give me a compiler flag that will error out on UB?"
They pointed me to things like this:

https://blog.regehr.org/archives/213

>> There is _tons_ of this floating around with respect to the
>> memory model, which wasn't even specified until C11, even though
>> we've been writing multithreaded C programs since the 70s (e.g.
>> the Unix kernel).
>>
>> And UB is extraordinarily easy to trip over in C. For example,
>> consider this almost trivial function:
>>
>> uint16_t
>> mul(uint16_t a, uint16_t b)
>> {
>> return a * b;
>> }
>
>OK, I have to ask. "UB" means "undefined Behaviour", right?
>Just so I know we are talking about the same thing here.

Yes, but I don't think we're talking about the same thing.

This may be interesting to you:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

>Exactly. A good programmer would have done it correctly and not
>written it relying on UB. That's my point.

You're conflating correctness with undefined behavior, when the
two are not equivalent. Most "good" programmers wouldn't even
know that it was UB, and not all UB is bad. If we tested _every
possible situation_ in C for UB, we'd have unwieldy programs.

>> In Rust, we'd write it as:
>>
>> fn mul(a: u16, b: u16) -> u16 {
>> a.wrapping_mul(b)
>> }
>>
>> In Rust, by default, _any_ overflow can panic the program, but
>> we can explicitly request modular arithmetic via `wrapping_mul`.
>
>Well, I don't know Rust so I really have no idea what that means.

As I said before to Simon, I highly encourage you to have a go
at poking at it a bit.

>But, once again, it looks like we are trying to create languages
>who's intent is to stop programmers from shooting themselves in
>the foot.

Yes. I also have a guard on my chainsaw, even though I know how
to use it properly.

>A better idea would be teaching the programmer not to
>shoot himself in the foot because if you rely on a language to do
>it programmers will continue to shoot themselves in the foot.

Sadly, 65 years of industry history has shown that to be pure
fantasy. Simply put, our best and brightest programmers write
buggy programs. Many of them wrote those buggy programs decades
ago.

After a few painful experiences, the very best of those develop
and adopt tools that allow them to do so more safely.

As I mentioned, concurrency is going to be a big source of this
sort of UB-driven "bug" in the coming years. Given that e.g.,
C didn't have a standard memory model when the 1988 ANSI
standard was written, associated UB wasn't even a thing then.
Claiming that someone who wrote multithreaded code in ANSI C in
the 90s that exhibits UB with respect to the most recent
standards is a "truly bad programmer" is disingenuious at best.

- Dan C.

On 4/5/2022 1:25 PM, Simon Clubley wrote:
> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>
>>> Why wasn't Python 3 just another language mode in the existing compiler
>>> instead of being a whole different compiler ?
>>
>> (ignoring that I would not call Python a compiler)
>>
>
> In that case, would you have said (for example) UCSD Pascal wasn't
> a compiler ?

I have never used USCD Pascal, but I assume that it has a compilation
step, so NO.

> Python can output .pyc files but also has a way of running code
> interactively if desired.

Modules get saved as .pyc files when first used.

I would call that "caching of intermediate code for
interpretation" and not "compilation" but the difference
between "caching of intermediate code for interpretation"
and "JIT compilation" is pretty thin.

But for no other reasons than common custom, then
I do not consider Python (CPython that is)
compiled.

Arne

On 06/04/2022 00:14, Arne Vajhøj wrote:
> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>>
>>>> Why wasn't Python 3 just another language mode in the existing compiler
>>>> instead of being a whole different compiler ?
>>>
>>> (ignoring that I would not call Python a compiler)
>>>
>>
>> In that case, would you have said (for example) UCSD Pascal wasn't
>> a compiler ?
>
> I have never used USCD Pascal, but I assume that it has a compilation
> step, so NO.
>
>> Python can output .pyc files but also has a way of running code
>> interactively if desired.
>
> Modules get saved as .pyc files when first used.
>
> I would call that "caching of intermediate code for
> interpretation" and not "compilation" but the difference
> between "caching of intermediate code for interpretation"
> and "JIT compilation" is pretty thin.
>
> But for no other reasons than common custom, then
> I do not consider Python (CPython that is)
> compiled.
>
> Arne
>

UCSD 'compilers' famously compiled to a pseudo code that was then
interpreted. Didn't go down well then...

--
Chris

On 4/4/2022 11:47 PM, Dave Froble wrote:
> On 4/4/2022 10:18 PM, Arne Vajhøj wrote:
>> Code should be enhanced and improved, but preferably to meet
>> increase business demand not to keep up with an ever changing
>> language standard.
>
> Yes, this is the key.
>
> Some time ago, perhaps in the 1990s,  not sure, the Basic developers
> took a look at things in general, and declared "we can implement just
> about anything". Basic got the RECORD statement, basically similar to
> structures in C, and some other things.  The concept was "add helpful
> things, but don't break anything". That was rather useful.
>
> Another example, I can use Visual Basic a bit.  I cannot use VB .NET.
> Not sure of all the differences, but a VB program will not compile in
> .NET.  That was rather distasteful.

DEC/VMS Basic has been very compatible as you have explained many times.
Lot of credit to DEC/CPQ/HP(E)/VSI for that.

Microsoft has sort of 3 generations of Basic:
* The DOS Basic's (GW Basic, QBasic etc.)
* VB especially VB6
* VB.NET

Big changes between them.

But a lot was give due to the difference in nature.

The first is really just a Basic interpreter/compiler (depending
on what flavor).

The second was a RAD tool with tight integration with COM.

The third was a full blown OO language integrated with .NET - some
consider it "C# with VB syntax".

Full compatibility may have been very difficult to achieve.

Arne

On 4/5/2022 9:04 AM, Bill Gunshannon wrote:
> So, I have been following this discussion for some time now.  I have
> never used Rust.  I have never even looked at Rust. But I do have one
> question.
>
> Just what is it that Rust can do that none of the already existing
> languages could do?

(this is going to be a bit high level as I don't code in Rust)

There is probably nothing that Rust can do that other languages
can't do. Most stuff can be done in any language.

But there may be some things where Rust is better than other
languages.

It is a modern language in the low level category.

Modern means that it has looked at problems with older
languages and tried to fix those.

Low level makes it rare, because there are not many modern
languages that are low level aka intended to be close to
the metal and able to be used for OS and similar code.

Go to high level code for business application and there
are a ton of languages:
* JVM languages - Java, Kotlin, Scala, Groovy
* .NET languages - C#, VB.NET
* JavaScript, TypeScript, Dart
* PHP, Hack
* modern C++
* Python
* Ruby
and that is just the most widely used one - there are dozens more.

For low level I can only think of two: Rust and Go. And they seem to
have found different markets - the OS people like Rust and the
container people like Go.

C and C++ are currently dominating the low level code area, but
there are some well known problem.

Two of those problems are:
* buffer overruns
* memory leaks

Of course it is possible to write C and C++ code without risk
of buffer overruns and memory leaks.

But decades of experience shows that at scale like hiring 100
average developers to write 1 million lines of code, then a
number of those problems get introduced.

Rust avoid those.

Rust checks memory access *unless* in an unsafe block (idea borrowed
from C# language). As a low level language Rust has the need to be able
to do some flexible memory access - I can not imagine it is
possible to write a device driver if only able to access memory
in variables in the program.

Rust has a unique approach to memory handling based on
ownership (idea borrowed from modern C++ best practice
not C++ language) that avoids memory leaks without GC - as
a low level language that may be used in real time
context, then the standard solution to avoid memory
leaks in high level languages GC could be problematic.

Arne

On 4/5/2022 3:21 PM, Bill Gunshannon wrote:
> On 4/5/22 14:55, Dan Cross wrote:
>> Hmm, that's a third-party package using unsafe code.

>> That's a third-party package using unsafe code.

>> I don't think it has much to do with what I said above at all,
>> frankly.  I never said that the language was a panacea that
>> prevents _all_ bugs.  But it significantly raises the bar over
>> just about everything else out there.
>
> And then provides a way to override all the safeties because sometimes
> you just need to get the job done.  By the way, for the few remaining
> Ada advocates out there, Ada did the same thing with allowing safeties
> to be turned off so you could write "unsafe" but functional code.  So
> did most versions of Pascal.  C just doesn't make you turn the safeties
> on and off.

I think there is a big difference between what older languages (Ada,
Pascal etc.) did and what Rust/C# does with unsafe blocks.

The older languages typical enable/disable per compilation
unit and common practice is to enable/disable for the entire
project.

(admitted Ada can simulate a block with pragma's)

The Rust/C# approach make it easier to limit the unsafe
part of the code.

And this is not just theory. It can be confirmed by looking
at real world code.

For C# then practically nobody use unsafe - it must be like
0.001% of all C# code that is unsafe.

For Rust the number is probably a bit higher as Rust is used
for more low level stuff. But the fraction typical given
on the net is 1%.

And that percentage does matter. It is way easier to do
extensive code review of memory access in 1% of the code
than in 100% of the code.

Arne

On 04/04/22 18:56, Simon Clubley wrote:
> On 2022-04-04, Arne Vajhøj<arne@vajhoej.dk> wrote:
>> On 4/4/2022 8:28 AM, Simon Clubley wrote:
>>> 2) No official ISO or similar language standard I can rely on 5/10/20 years
>>> from now when I need to work on my safety or general production critical
>>> code at that point.
>>>
>>> Even though many of the Rust people appear not to understand this, the
>>> lack of those guarantees is a _massive_ problem in the real world.
>>
>> Not really. Lot of popular languages are not formally standardized.
>> Python and PHP are not standardized. C# is/was standardized but the
>> standard is 6 versions behind. It took 13 years before C++ got
>> standardized.
>>
>
> You have just made my point for me Arne. Or to put it another way,
> Python 2 to Python 3.
>
> Why wasn't Python 3 just another language mode in the existing compiler
> instead of being a whole different compiler ?
>
> Why did Python 2.7 stay around for as long as it did ? How many are still
> using it these days due to an existing code base ?
>
> I can compile C89 code on a compiler 33 years later. When another standard
> for C is released, it becomes just another language mode in the existing
> compilers and all the existing C standards are still supported.
>
> How confident are you that I can compile C89 code in yet another 10 years ?
>
> In comparison, how confident are you that I can compile existing Python 3
> or Rust code in another 10 years ?
>
> What's to stop the Rust people from having some great language revamp a
> few years from now and then stop supporting the existing language variant ?
>
> The Python people did that and it's a _much_ more popular language than
> Rust so what's to stop the Rust people from doing the same thing ?
>
>> If there is a desire for ISO Rust then it could happen. The likelihood
>> of it happening will increase if different implementations show up.
>>
>>> 3) Unlike mainstream programming languages, the Rust community always
>>> seems to be lurching from one social drama to the next.
>>>
>>> That in itself is an instant switchoff because the community is one
>>> major social crisis away from falling apart (at least until it's then
>>> rebuilt and a new direction emerges).
>>>
>>> You can't rely on a programming language when something like that is
>>> a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
>>> language standards groups for example.
>>
>> I don't think the number of heated discussions in the rust community
>> is unique. They may be a bit more transparent about it than most. And
>> the "internet tabloid press" loves that type of stuff. But has anything
>> actually been significant delayed due to it?
>>
>
> I'm talking about the social stuff, not the technical stuff.
>
> It's the stuff that can become so toxic, it can cause a community
> itself to become damaged.
>
> Simon.
>

I think the point is that languages take time to evolve and the path
can be unstable until there is enough critical mass to produce a fully
documented and standard version. I would expect that to take a decade
or more. No good for serious work without that professionalism. Toy
and experimental otherwise.

That's the great thing about C, so old now that all the real
issues have been thrashed out...

Chris

On 4/5/22 19:22, Chris Townley wrote:
> On 06/04/2022 00:14, Arne Vajhøj wrote:
>> On 4/5/2022 1:25 PM, Simon Clubley wrote:
>>> On 2022-04-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 4/4/2022 1:56 PM, Simon Clubley wrote:
>>>>>
>>>>> Why wasn't Python 3 just another language mode in the existing
>>>>> compiler
>>>>> instead of being a whole different compiler ?
>>>>
>>>> (ignoring that I would not call Python a compiler)
>>>>
>>>
>>> In that case, would you have said (for example) UCSD Pascal wasn't
>>> a compiler ?
>>
>> I have never used USCD Pascal, but I assume that it has a compilation
>> step, so NO.
>>
>>> Python can output .pyc files but also has a way of running code
>>> interactively if desired.
>>
>> Modules get saved as .pyc files when first used.
>>
>> I would call that "caching of intermediate code for
>> interpretation" and not "compilation" but the difference
>> between "caching of intermediate code for interpretation"
>> and "JIT compilation" is pretty thin.
>>
>> But for no other reasons than common custom, then
>> I do not consider Python (CPython that is)
>> compiled.
>>
>> Arne
>>
>
> UCSD 'compilers' famously compiled to a pseudo code that was then
> interpreted. Didn't go down well then...

Sadly, too far ahead of its time. And then there were the people
cheating UCSD Pascal developers out of the value of their IP.

Believe it or not, last I saw it was still actively being sold in
Europe by the last remaining UCSD Licensee.

I always wanted a Western Digital Pascal Microengine. :-)

bill

On 4/5/22 19:46, Arne Vajhøj wrote:
>
> C and C++ are currently dominating the low level code area, but
> there are some well known problem.
>
> Two of those problems are:
> * buffer overruns
> * memory leaks
>

Both those problems were fixed 40 years ago. The fixes were
ignored and the company offering Safe C went out of business.

bill

On 4/5/2022 4:21 PM, Bill Gunshannon wrote:
> On 4/5/22 15:59, Dan Cross wrote:
>> The point is that, even though C has a standard, it is riddled
>> with almost inescapable UB, and compiler writers can, and WILL,
>> take advantage of that over time.  New versions of compilers may
>> well introduce UB-based optimizations that fundamentally alter
>> the behavior and indeed the correctness of programs without the
>> programs themselves changing.
>
> But, that was my point exactly.  A definition of "UB" means that
> particular case should never be used because the results are "UB".
> Not the fault of the language.  Not the fault of the compiler.
> Strictly the fault of truly bad programmers.

There are two schools of thought about that.

A) Those that believe that if the language/compiler allows for
good code then all is good and when the code does not
work then it is the fault of the programmer.

B) Those that believe the language/compiler should make
it very difficult for developers to make bad code.

#A can be called "disaster".

#B can be called "good engineering".

Because it is irrelevant what "can be done". It is
what "is actually done" that matters.

And experience shows that if the language/compiler
allows for lots of undefined behavior then for large
projects with many developers then undefined behavior
sneak into the project.

Arne

On 4/5/2022 8:08 PM, Bill Gunshannon wrote:
> On 4/5/22 19:46, Arne Vajhøj wrote:
>> C and C++ are currently dominating the low level code area, but
>> there are some well known problem.
>>
>> Two of those problems are:
>> * buffer overruns
>> * memory leaks
>
> Both those problems were fixed 40 years ago.  The fixes were
> ignored and the company offering Safe C went out of business.

They were not fixed as the current C compilers allow
the problems.

Maybe they could have been fixed, but that does not really
help those with C code today.

Arne

In article <t2ilf1$18mj$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>I think the point is that languages take time to evolve and the path
>can be unstable until there is enough critical mass to produce a fully
>documented and standard version. I would expect that to take a decade
>or more. No good for serious work without that professionalism. Toy
>and experimental otherwise.

Java doesn't have a "standard" in the sense described here, but
much as I don't care for it as a language I'd be hard pressed to
describe it as a "toy" or "no good for serious work."

>That's the great thing about C, so old now that all the real
>issues have been thrashed out...

That's definitely not true. Those of us who follow the current
C standardization efforts see lots of things that are far from
settled.

- Dan C.