[Info-vax] C et al (was: Re: Rust as a HS language, was: Re: Quiet?)

[Dan Cross]

In article <6254bb5f$0$705$14726298 at news.sunsite.dk>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 4/11/2022 9:14 AM, Simon Clubley wrote:
>> On 2022-04-10, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> On 2022-04-10 02:29:53 +0000, Stephen Hoffman said:
>>>> My usual pointer to just what volatile provides, and doesn't provide:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
>>>
>>> For those that believe there is but one write with volatile, there's
>>> one write per byte yes, but there can be multiple and arbitrary-ordered
>>> writes involved within that operation.
>> 
>> Any compiler doing anything as brain-dead as that would instantly be
>> dropped and if it was an open-source compiler, would instantly be
>> forked, XFree86 style, and the brain-dead additions removed.
>
>If we look at the language standard, then ISO C has a lot of
>undefined and implementation specific behavior. There are lot
>of C code but not that much which is guaranteed to work by ISO C
>standard.

This thread started off with assertions that one of the big
problems with Rust is that it doesn't have an official standard.
Now we find that the standard has behavior that is surprising,
even to seasoned hands!  Indeed, this was one of the impetuses
for the creation of Rust.

>"C deemed not brain-dead by Simon" is a very unofficial standard
>that is not so relevant.
>
>The practical impact may not be so big though.
>
>I suspect that your use case may be typical for such code:
>
># Reasoning: the most common use of volatile I have in my code is
># for reading and writing to device registers.
>
>You just need to know that the compiler you use will
>do what you expect.

An issue here is that the compiler may change, even over the
lifetime of a single project.  Linux started with some version
of GCC; now it will compile with much more recent versions
(that are sufficiently different that they're different
compilers for all intents and purposes) and clang, which wasn't
even a twinkle in Lattner's eye when Torvalds started.

>You do not care if some compiler
>somewhere else does not, because such code would
>need to be rewritten anyway if ported read as
>reimplemented for that platform.

Or the compiler version changes or you port to a new hardware
platform or....

>C is more portable than assembler, but it is not that easy
>to write 100% portable code in C. But then like above: if
>100% portability is a requirement, then C is most likely not
>the right choice of language!

Even portability to what one might call oneself over time!

	- Dan C.