In article <a3b299ca-1f94-4f3f-9e9d-21b8d7a5fd30n@googlegroups.com>,
Don Baccus <dhogaza@gmail.com> wrote:
>On Friday, April 8, 2022 at 10:13:21 AM UTC-7, Arne Vajhøj wrote:
>> 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;
>
>Yes, ADA took the idea from Pascal.
>
>The Oregon Software Pascal-2 compiler leveraged this to
>reduce checking (when checking was enabled) and that worked
>reasonably well if the programmer was careful about declaring
>ranges when it made sense to do so.

It's really refreshing the way a strong type system can be
leveraged to reduce errors by eliminating states that just
cannot be expressed.

About the best explanation I've ever seen of this is this post
from Alexis King:

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

The gist of it is that if one can "parse" data into a form so
that the type system encapsulates the required invariants of the
data, then one needed validate it at the point of use. The type
becomes something of a token that proves that the data was
validated, and then the type system "proves" that this invariant
holds throughout the program.

- Dan C.

- Dan C.

In article <6250369b$0$698$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>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.

The point remains: there's little evidence available that Robert
C Martin is as qualified of a programmer as he claims.

On the other hand, his publicly available work is of only
middling quality, at best, and much of his discussions of his
own qualifications amount to an appeal to authority. For
example, he did an "Ask Me Anything" on Hashnode and made this
comment:

Meanwhile, I've been a programmer for 48 years.
That's something of a rarity. Very few people alive
have been coding for 48 years straight. That sheer
level of experience puts me in a position of some
authority. I'm also a tolerably good writer, and
that helps.

(https://hashnode.com/post/i-am-robert-c-martin-uncle-bob-ask-me-anything-cjr7pnh8g000k2cs18o5nhulp
for context)

Well, no. Merely doing something for a long time does not a
priori put one in a position of authority as an expert in that
thing. There are those that balance their checkbooks for 48
years and that does not make them expert economists.

I have no argument that Mr Martin is a very accomplished
consultant and author. But that doesn't mean he's an expert in
the things that he consults on or writes about; I've seen little
evidence of his expertise as a software engineer, and indeed,
have seen disconfirming evidence.

- Dan C.

On 2022-04-09, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <t2pn8f$r5q$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>>
>>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.
>
> The last time this came up where I was involved, the murky stuff
> revolved around precise semantics of generated loads and stores.
> What you wrote above is true, but suppose I'm doing multiple
> stores into aligned buffers; can the compiler lower into stores
> into a larger datum, or must they be kept distinct? That is,
> suppose I'm writing a bunch of uint16_t's from an aligned source
> into an aligned destination; can the compiler turn that into
> corresponding loads/stores of uint32_t? Can it write to the
> same byte twice? And how do I work with volatile byte buffers
> without memcpy?
>

Volatile is very simple as far as I am concerned when answering
the above questions.

One read in the source code is exactly one read in the generated code.

One write in the source code is exactly one write in the generated code.

A set of reads or a set of writes cannot be combined.

If the source code asks for two 16-bit reads or writes, then that's
exactly what it gets. This cannot be converted to a single 32-bit
read or write.

If the compiler does anything else, it's broken.

Reasoning: the most common use of volatile I have in my code is
for reading and writing to device registers. If the compiler did
any of the above in your questions, it would break my code.

I would never use memcpy() with volatile BTW, I would always read
and write the volatile area directly in my source code if I was
working with something larger than a set of registers.

Also, when it comes to talking to hardware, the compiler has no
idea what the hardware alignment is or what the size of the
register the code is talking to is. It has to use the information
in the source code and nothing else.

Simon.

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

On 4/9/2022 4:27 AM, chris wrote:
> On 04/08/22 01:36, Arne Vajhøj wrote:
>> On 4/7/2022 2:58 PM, Dave Froble wrote:
>>> On 4/7/2022 1:39 PM, Simon Clubley wrote:
>>>> BTW, testing can only prove the presence of bugs and not the absence
>>>> of them. Someone else can still come along and do testing in a
>>>> different
>>>> way that finds undiscovered issues. Look at the stuff about EVL that
>>>> I posted recently as an example.
>>>
>>> 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.
>>
>> True.
>>
>> But not particular relevant.
>>
>> Too many cases to test.
>>
>> If your program take 1 KB of input then there are
>> 2**8192 possible inputs. That is a pretty big number.
>>
>> But it is what it takes to prove that this
>> program is correct by test.
>
> Good design range checks all input against the limits
> that the code can handle. Anything else is sloppy, but is
> seen everywhere these days. No excuse for design errors
> like that, as it's so easy to avoid.
>
>> Of course you can probably pick a couple of handful
>> careful designed test cases and if they work, then you
>> are somewhat optimistic that the program will work in
>> general. But that is different from proving.

With some skill one can pick the critical values with 99 or
99.9 certainty. But it it is not 100% and therefore not proof.

> For work here, tend to write a test harness for every
> module as part of the build process, with data designed
> to stress test the code well outside expected limits,
> as well as with valid data.

I think that is called unit testing with 100% code
coverage in today's terminology.

And it is the right thing to do.

> Of course, that doesn't prove that the overall system
> design is correct and that is often where the real
> testing problems arise...

Yes.

Arne

On 4/9/2022 3:53 PM, Dan Cross wrote:
> In article <6250369b$0$698$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> 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.
>
> The point remains: there's little evidence available that Robert
> C Martin is as qualified of a programmer as he claims.

Except for those contributing to open source project you will
never know any details about what they have done as developer.

But does it matter?

I believe he is most known for Agile Manifesto and Clean Code.

The Agile Manifesto is about project management. So it is actually
more relevant that he has been in development management than he has
been a great programmer.

Clean Code is about development. But the content does not really
require any advanced programming skills. It requires having
seen a lot of code and been able to deduce some lessons
learned from the code and able to present them in an easy form.
So having been a consultant and been around a lot of places
is better than having worked on a few big software projects.

> On the other hand, his publicly available work is of only
> middling quality, at best,

The agile manifesto has had a great impact on the IT industry.

Clean Code is almost in top 10 when developers rate books.

The impact is there.

You may disagree with his opinions, you may dislike his
writing style etc., but need to realize that his work
has had an impact.

Arne

On 4/8/2022 8:03 PM, chris wrote:
> On 04/08/22 01:07, Arne Vajhøj wrote:
>> On 4/7/2022 5:50 PM, chris wrote:
>>> 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...
>>
>> Hopefully project managers are never involved in making
>> decisions about tech stack as it is not a project management
>> matter.
>>
>> Decisions about tech stack is an architecture matter and
>> architects should be the primary decision makers. They
>> can solicit input from software engineering to verify
>> that would should work actually does work in practice.
>
> In companies i've worked for, many of them, only the tech /
> team leaders have enough of a grip on a project to know what
> skills are required for the task and the sort of personality
> that would fit into the team. In the UK, it's usually someone
> at senior tech level that runs the interview, never HR.
> HR may run the background checks, but are rarely qualified
> to ask the right questions from a tech point of view.

Different companies have different processes.

But for obvious reasons usually developers get evaluated by current
or past developers, project managers by current or past project
managers and architects by current or past architects. Hard to
evaluate technical skills one does not have self.

But that has nothing to do with the fact that tech stack decisions
is an architecture matter and not a project management matter.

Arne

On 4/9/2022 4:11 AM, chris wrote:
> On 04/08/22 01:07, Arne Vajhøj wrote:
>> On 4/7/2022 5:50 PM, chris wrote:
>>> 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...
>>
>> Hopefully project managers are never involved in making
>> decisions about tech stack as it is not a project management
>> matter.
>>
>> Decisions about tech stack is an architecture matter and
>> architects should be the primary decision makers. They
>> can solicit input from software engineering to verify
>> that would should work actually does work in practice.
>
> Nit picking semantics there. The project manager / team leader
> is usually at least as technically aware and switched on as
> the rest of the team.

Some project managers are (developer) technical because they come from a
development background. But some are not. Because project
management is not a (developer) technical discipline. It is about
project planning, project estimation, people management, risk
evaluation and mitigation, managing customer/management expectations
etc..

> Also, "tech stack" may be initiated by
> one of two people, but that is usually discussed and often
> changed once it reaches peer group review. Shared responsibility
> and many eyes helps build better product...

That is cowboy architecture.

Places with a more structured approach have architects
doing architecture work.

Arne

On 4/9/2022 6:45 AM, Johnny Billquist wrote:
> On 2022-04-08 22:21, Arne Vajhøj wrote:
>> 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.
>
> Hum. I don't know what the two of you are going on about. :-)
>
> As far as I know, you can still compile a program that don't have
> function prototypes in current C, and you can definitely do it in C89.
>
> So K&R style code is still compilable. Obviously, "modern" C won't pass
> the K&R compiler, but that's more expected.

I had very limited exposure to K&R C.

I know that ANSI C added a bunch of features and changed
function headers from:

void f(a)
int a;
{

to:

void f(int a)
{

which is a trivial change but a change present a lot of places in code.

But are you saying that an ANSI C compiler also supports the
old style function?

Arne

In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
(Arne Vajh�j) wrote:

> But are you saying that an ANSI C compiler also supports the
> old style function?

At least some of them do. The compiler I had handy was on Windows, Visual
Studio 2019. I just compiled this:

#include <stdio.h>
int main( argc, argv)
int argc;
char *argv[];
{ int i;
printf( "Hello, world\n");
for( i = 1; i < argc; i++)
{
printf( "argument %d is '%s'\n", i, argv[i]);
}
}

With this command line:

cl /W4 /MD /std:c11 /Za kr_world.c

/W4 All the warnings.
/MD Use the DLL form of the run-time library.
/std:c11 Compile according to the C2011 standard.
/Za Be pedantic about standard compliance.

It compiles with one warning, about the use of an old-style declarator,
and runs correctly.

John

On 4/9/2022 6:09 PM, John Dallman wrote:
> In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>> But are you saying that an ANSI C compiler also supports the
>> old style function?
>
> At least some of them do. The compiler I had handy was on Windows, Visual
> Studio 2019. I just compiled this:
>
> #include <stdio.h>
> int main( argc, argv)
> int argc;
> char *argv[];
> {
> int i;
> printf( "Hello, world\n");
> for( i = 1; i < argc; i++)
> {
> printf( "argument %d is '%s'\n", i, argv[i]);
> }
> }
>
> With this command line:
>
> cl /W4 /MD /std:c11 /Za kr_world.c
>
> /W4 All the warnings.
> /MD Use the DLL form of the run-time library.
> /std:c11 Compile according to the C2011 standard.
> /Za Be pedantic about standard compliance.
>
> It compiles with one warning, about the use of an old-style declarator,
> and runs correctly.

In that case I think most K&R C code should compile with ANSI C.

Arne

On 2022-04-09 22:10:00 +0000, John Dallman said:

> In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
> (Arne Vajhøj) wrote:
>
>> But are you saying that an ANSI C compiler also supports the
>> old style function?
>
> At least some of them do. The compiler I had handy was on Windows,
> Visual Studio 2019. I just compiled this:
>
> #include <stdio.h>
> int main( argc, argv)
> int argc;
> char *argv[];
> {
....

Enjoy that K&R C syntax while it lasts (C17 and earlier), as C2X
(probably C23) expects to deprecate K&R function declarations.

Here's the (accepted) proposal (for deprecation):

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf

More on C2X (though not the most current list):

https://habr.com/en/company/badoo/blog/512802/

Some opinions on the C ABI, and the "fun" that is parsing C more generally:

https://gankra.github.io/blah/c-isnt-a-language/

The IDE I routinely use live-parses C source code in the editor input
using callable Clang, which makes finding errors faster, and makes
source code completion near prescient. At some point, maybe that
arrives in VSI VSC or LSEDIT or some other IDE...

A proposal discussing part of the mess that is C signed and unsigned handling:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2837.pdf

Some light reading on hardware and language memory models:

https://research.swtch.com/mm

Memory de-initialization (and C is bad at this, as are many other languages):

https://gankra.github.io/blah/deinitialize-me-maybe/

Undefined behaviour sanitizer (UBSan):

https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

And since there's been a discussion of assembly languages else-thread,
here is an intro to that of RISC-V:

https://mcyoung.xyz/2021/11/29/assembly-1/

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

Previous discussion of the C volatile keyword here in c.o.v.:

https://groups.google.com/g/comp.os.vms/c/Zf9tM2UkKAE/m/awJ6Tp-yAQAJ

If you have lots of C around and are thinking about alternatives, maybe
look at zig:

https://ziglang.org

https://ziglang.org/documentation/master/#Introduction

....or Crystal:

https://crystal-lang.org

And included here mostly for grins, a C interpreter:

https://github.com/asvitkine/ccons#readme

I'm interested in alternatives to C, as well as at least some of what
C2x will seemingly bring to existing and new C code.

If C, Swift, Go, Rust, Crystal, or Zig works for y'all, great. Or
BASIC, COBOL, Macro32, C++, or Fortran/FORTRAN, for that matter. Even
Java or some other JVM, or Ada. Whatever. Use what works for your task
and your staff and your needs, whether the languages are familiar to
you, or new.

ps:

Understanding other (and completely different) sorts of strings and
string encodings:

https://www.sapiens.org/language/khipu-andean-writing/

And understanding and maintaining skills:

https://codewithoutrules.com/2017/10/23/obsolete-skills/

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-04-09 21:35, Dan Cross wrote:
> In article <t2pn8f$r5q$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> 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.
>
> The last time this came up where I was involved, the murky stuff
> revolved around precise semantics of generated loads and stores.
> What you wrote above is true, but suppose I'm doing multiple
> stores into aligned buffers; can the compiler lower into stores
> into a larger datum, or must they be kept distinct? That is,
> suppose I'm writing a bunch of uint16_t's from an aligned source
> into an aligned destination; can the compiler turn that into
> corresponding loads/stores of uint32_t? Can it write to the
> same byte twice? And how do I work with volatile byte buffers
> without memcpy?

No. You cannot combine two stores into one. That could mean something
different when dealing with hardware, and would break the semantics
guaranteed by volatile..

And no, one write can also not be changed into two writes. Same reason.

The actual read/write itself might have meaning, so the compiler cannot
do anything beyond exactly the operations on the variable specified in
the code.

This might be accessing hardware registers, where the read/write in
itself triggers action. Combining two accesses into one might mean
something else to the hardware. If the compiler were allowed to do that,
you would not be able to interact with the hardware correctly.

memcpy have a high risk of breaking this, since memcpy is a function
that are unaware of the volatile property. Properties like volatile
don't implicitly carry across function calls. Same with const.
In C, such properties only exists on a variable when explicitly declared
in the code.
So don't use memcpy, or any other function that isn't explicitly aware
of the volatile status of a variable.

>> There are other parts that are much more devious in C these days.
>
> Can't argue with that. :-)

:-)

Johnny

On 4/9/22 20:35, Arne Vajhøj wrote:
> On 4/9/2022 6:09 PM, John Dallman wrote:
>> In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> (Arne Vajhøj) wrote:
>>> But are you saying that an ANSI C compiler also supports the
>>> old style function?
>>
>> At least some of them do. The compiler I had handy was on Windows, Visual
>> Studio 2019. I just compiled this:
>>
>> #include <stdio.h>
>> int main( argc, argv)
>> int argc;
>> char *argv[];
>> {
>>     int i;
>>     printf( "Hello, world\n");
>>     for( i = 1; i < argc; i++)
>>     {
>>         printf( "argument %d is '%s'\n", i, argv[i]);
>>     }
>> }
>>
>> With this command line:
>>
>>      cl /W4 /MD /std:c11 /Za kr_world.c
>> /W4             All the warnings.
>> /MD             Use the DLL form of the run-time library.
>> /std:c11        Compile according to the C2011 standard.
>> /Za             Be pedantic about standard compliance.
>>
>> It compiles with one warning, about the use of an old-style declarator,
>> and runs correctly.
>
> In that case I think most K&R C code should compile with ANSI C.
>

Trivial programs, probably. I just tried to compile a couple pieces
of the Ultrix-11 3.1 source with gcc and after over 100 warnings and
4 errors in a 1000 line piece of code it just stops.

bill

On 4/9/22 22:29, Stephen Hoffman wrote:
> On 2022-04-09 22:10:00 +0000, John Dallman said:
>
>> In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
>> (Arne Vajhøj) wrote:
>>
>>> But are you saying that an ANSI C compiler also supports the
>>> old style function?
>>
>> At least some of them do. The compiler I had handy was on Windows,
>> Visual Studio 2019. I just compiled this:
>>
>> #include <stdio.h>
>> int main( argc, argv)
>> int argc;
>> char *argv[];
>> {
> ...
>
> Enjoy that K&R C syntax while it lasts (C17 and earlier), as C2X
> (probably C23) expects to deprecate K&R function declarations.
>
> Here's the (accepted) proposal (for deprecation):
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf
>
> More on C2X (though not the most current list):
>
> https://habr.com/en/company/badoo/blog/512802/
>
> Some opinions on the C ABI, and the "fun" that is parsing C more generally:
>
> https://gankra.github.io/blah/c-isnt-a-language/
>
> The IDE I routinely use live-parses C source code in the editor input
> using callable Clang, which makes finding errors faster, and makes
> source code completion near prescient. At some point, maybe that arrives
> in VSI VSC or LSEDIT or some other IDE...
>
> A proposal discussing part of the mess that is C signed and unsigned
> handling:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2837.pdf
>
> Some light reading on hardware and language memory models:
>
> https://research.swtch.com/mm
>
> Memory de-initialization (and C is bad at this, as are many other
> languages):
>
> https://gankra.github.io/blah/deinitialize-me-maybe/
>
> Undefined behaviour sanitizer (UBSan):
>
> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
>
> And since there's been a discussion of assembly languages else-thread,
> here is an intro to that of RISC-V:
>
> https://mcyoung.xyz/2021/11/29/assembly-1/
>
> 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
>
> Previous discussion of the C volatile keyword here in c.o.v.:
>
> https://groups.google.com/g/comp.os.vms/c/Zf9tM2UkKAE/m/awJ6Tp-yAQAJ
>
> If you have lots of C around and are thinking about alternatives, maybe
> look at zig:
>
> https://ziglang.org
>
> https://ziglang.org/documentation/master/#Introduction
>
> ...or Crystal:
>
> https://crystal-lang.org
>
> And included here mostly for grins, a C interpreter:
>
> https://github.com/asvitkine/ccons#readme

The Safe C I mentioned also had a C Interpreter to help with code
development. So, no surprise to see another one.

bill

On 4/10/2022 9:43 AM, Bill Gunshannon wrote:
> On 4/9/22 20:35, Arne Vajhøj wrote:
>> On 4/9/2022 6:09 PM, John Dallman wrote:
>>> In article <6251fe92$0$696$14726298@news.sunsite.dk>, arne@vajhoej.dk
>>> (Arne Vajhøj) wrote:
>>>> But are you saying that an ANSI C compiler also supports the
>>>> old style function?
>>>
>>> At least some of them do. The compiler I had handy was on Windows,
>>> Visual
>>> Studio 2019. I just compiled this:
>>>
>>> #include <stdio.h>
>>> int main( argc, argv)
>>> int argc;
>>> char *argv[];
>>> {
>>>     int i;
>>>     printf( "Hello, world\n");
>>>     for( i = 1; i < argc; i++)
>>>     {
>>>         printf( "argument %d is '%s'\n", i, argv[i]);
>>>     }
>>> }
>>>
>>> With this command line:
>>>
>>>      cl /W4 /MD /std:c11 /Za kr_world.c
>>> /W4             All the warnings.
>>> /MD             Use the DLL form of the run-time library.
>>> /std:c11        Compile according to the C2011 standard.
>>> /Za             Be pedantic about standard compliance.
>>>
>>> It compiles with one warning, about the use of an old-style declarator,
>>> and runs correctly.
>>
>> In that case I think most K&R C code should compile with ANSI C.
>
> Trivial programs, probably.  I just tried to compile a couple pieces
> of the Ultrix-11 3.1 source with gcc and after over 100 warnings and
> 4 errors in a 1000 line piece of code it just stops.

OK.

But what are the problems?

Arne

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.

"...the Standard technically allows an implementation which touched
each target byte exactly once, one after the other, in an unspecified
order that could change on each execution."

And this all before we discuss the details of memory accesses and
"tearing" and caching and multiprocessing, and the rest of how the C
abstract machine differs from modern machines.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-04-10, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> Trivial programs, probably. I just tried to compile a couple pieces
> of the Ultrix-11 3.1 source with gcc and after over 100 warnings and
> 4 errors in a 1000 line piece of code it just stops.
>

Can you show us the warnings and errors please ?

Would be interesting to see what gcc is complaining about.

Try playing with the -std= command line option to see if that changes
anything.

Perhaps gcc needs its own version of a /standard=vaxc mode. :-)

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-10, Stephen Hoffman <seaohveh@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.

Simon.

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

In article <t2soi8$los$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-04-09, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> In article <t2pn8f$r5q$1@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>>
>>>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.
>>
>> The last time this came up where I was involved, the murky stuff
>> revolved around precise semantics of generated loads and stores.
>> What you wrote above is true, but suppose I'm doing multiple
>> stores into aligned buffers; can the compiler lower into stores
>> into a larger datum, or must they be kept distinct? That is,
>> suppose I'm writing a bunch of uint16_t's from an aligned source
>> into an aligned destination; can the compiler turn that into
>> corresponding loads/stores of uint32_t? Can it write to the
>> same byte twice? And how do I work with volatile byte buffers
>> without memcpy?
>>
>
>Volatile is very simple as far as I am concerned when answering
>the above questions.
>
>One read in the source code is exactly one read in the generated code.
>
>One write in the source code is exactly one write in the generated code.
>
>A set of reads or a set of writes cannot be combined.

Consider the case of structure assignment to a
volatile-qualified object. There's nothing in the standard
that guarantees that the above properties hold.

>If the source code asks for two 16-bit reads or writes, then that's
>exactly what it gets. This cannot be converted to a single 32-bit
>read or write.

Sadly, the standard makes no such guarantee, and cases have been
seen in the wild where that does not hold:

https://lists.llvm.org/pipermail/llvm-dev/2019-June/132817.html
https://llvm.org/pubs/2008-10-EMSOFT-Volatiles.pdf

>If the compiler does anything else, it's broken.
>
>Reasoning: the most common use of volatile I have in my code is
>for reading and writing to device registers. If the compiler did
>any of the above in your questions, it would break my code.

In the standard gives no such guarantee, then I'm afraid the
compiler isn't broken. That's what makes C so damned tricky
these days.

Your reasoning is sound. The compiler folks just don't care,
and the behavior is "implementation defined" (C11 6.7.3, par 7).

>I would never use memcpy() with volatile BTW, I would always read
>and write the volatile area directly in my source code if I was
>working with something larger than a set of registers.

Indeed, you _cannot_ use memcpy() with volatile; either pointer
argument would discard the `volatile` qualifier which is instant
UB. (C11 sec 6.7.3, par 6).

>Also, when it comes to talking to hardware, the compiler has no
>idea what the hardware alignment is or what the size of the
>register the code is talking to is. It has to use the information
>in the source code and nothing else.

The trouble is, the compiler doesn't know whether you're talking
to hardware or not; it just knows that something outside of the
view of the program _may_ change the value of an object that is
volatile-qualified.

Sadly, when dealing with things like, say, misaligned hardware
registers on some peripheral, about the only well defined thing
you can do is synthesize a char* that points to that register
and memcpy() into it. Even creating a misaligned pointer is UB
(C11 6.3.2.3 par 7). But since you can't memcpy() through a
volatile-qualified pointer, you can't do that.

Of course, most compilers will give you an escape hatch. But
relying on the semantics of `volatile` is fraught. See also
DR 476:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476

- Dan C.

In article <t2uc6n$hsu$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2022-04-09 21:35, Dan Cross wrote:
>> In article <t2pn8f$r5q$1@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> 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.
>>
>> The last time this came up where I was involved, the murky stuff
>> revolved around precise semantics of generated loads and stores.
>> What you wrote above is true, but suppose I'm doing multiple
>> stores into aligned buffers; can the compiler lower into stores
>> into a larger datum, or must they be kept distinct? That is,
>> suppose I'm writing a bunch of uint16_t's from an aligned source
>> into an aligned destination; can the compiler turn that into
>> corresponding loads/stores of uint32_t? Can it write to the
>> same byte twice? And how do I work with volatile byte buffers
>> without memcpy?
>
>No. You cannot combine two stores into one. That could mean something
>different when dealing with hardware, and would break the semantics
>guaranteed by volatile..

The problem, sadly, is that those semantics _aren't_ guaranteed
for volatile.

>And no, one write can also not be changed into two writes. Same reason.
>
>The actual read/write itself might have meaning, so the compiler cannot
>do anything beyond exactly the operations on the variable specified in
>the code.
>
>This might be accessing hardware registers, where the read/write in
>itself triggers action. Combining two accesses into one might mean
>something else to the hardware. If the compiler were allowed to do that,
>you would not be able to interact with the hardware correctly.
>
>memcpy have a high risk of breaking this, since memcpy is a function
>that are unaware of the volatile property. Properties like volatile
>don't implicitly carry across function calls. Same with const.
>In C, such properties only exists on a variable when explicitly declared
>in the code.
>So don't use memcpy, or any other function that isn't explicitly aware
>of the volatile status of a variable.

I'm afraid this is off. :-( Please see my other response.

- Dan C.

In article <6251f537$0$697$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/9/2022 3:53 PM, Dan Cross wrote:
>> The point remains: there's little evidence available that Robert
>> C Martin is as qualified of a programmer as he claims.
>
>Except for those contributing to open source project you will
>never know any details about what they have done as developer.
>
>But does it matter?

I think if one is going to claim expertise in some domain, one
should be able to provide evidence of one's bona fides, yes.

>I believe he is most known for Agile Manifesto and Clean Code.
>
>The Agile Manifesto is about project management. So it is actually
>more relevant that he has been in development management than he has
>been a great programmer.

Ok, that's fair.

>Clean Code is about development. But the content does not really
>require any advanced programming skills. It requires having
>seen a lot of code and been able to deduce some lessons
>learned from the code and able to present them in an easy form.
>So having been a consultant and been around a lot of places
>is better than having worked on a few big software projects.

Indeed, the content is poorly written, riddled with errors, and
not universally agreed upon. For instance:

https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ

(Note that Ousterhout has a strong track record of delivering
software.)

>> On the other hand, his publicly available work is of only
>> middling quality, at best,
>
>The agile manifesto has had a great impact on the IT industry.
>
>Clean Code is almost in top 10 when developers rate books.

That's sadly true. However, it's not a very good book.

https://qntm.org/clean
https://www.getrevue.co/profile/tech-bullshit/issues/tech-bullshit-explained-uncle-bob-830918

>The impact is there.
>
>You may disagree with his opinions, you may dislike his
>writing style etc., but need to realize that his work
>has had an impact.

I don't think I said that it didn't have an impact. I said that
he doesn't have a strong track record of producing software. He
has obviously had a large impact, but the impact has had a very
questionable effect on software quality. For that matter, see:
https://github.com/unclebob/PDP8EmulatorIpad/pull/2

- Dan C.

In article <t2q1u3$ddm$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:
>> In article <t2na4b$sdf$1@dont-email.me>,
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>>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.

It's worth pointing out immediately that none of these are in
any way "official". I'm sure I could find a number of similar
publications by, say, Ada neophytes, those enamoured with Lisp
but not skilled in that language, etc, that would have similar
issues.

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

You _don't_ invalidate _all_ the unique features and guarantees,
though. At least not without going ridiculously out of you way.

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

My reading of that excerpt is that the author is saying that in
C++ all code is de facto unsafe, and you have no notion of way
to tell if code is safe. In rust, writing unsafe code is
explicit.

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

Well, that's correct. But most Rust code isn't unsafe. C++ has
no analogous concept.

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

No, the author is correct; your mistake is that you do not know
what all of the safety guarantees are. For instance, unsafe
does not turn off the borrow checker, so unless you _really_ go
out of your way to create an invalid reference, you continue to
get the benefits of that. Of course, you can do something weird
like cast a reference to an integer, drop the referent, and then
cast that integer back to a reference, but at that point you're
going out of you way to violate the rules of the language, and
recall that the contract around `unsafe` is that the programmer
agrees to take on the burden of maintaining the language's
invariants.

Doing something like the above is the moral equivalent of a C
program that sets a floating point variable to some random
value, memcpy'ing the bit representation of the float into an
integer, casting that to a function pointer, and then blaming C
when the program crashes. Doctor, it hurts when I punch myself
in the face.

If you _do_ need to play shenanigans with passing around
references to hardware or through an FFI, it's your
responsibility to make sure you aren't violating the rules of
the language. But at least `unsafe` makes it clear where the
violations might be.

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

That's a logic bug in a system interface; it has nothing to do
with the language aside from being in a library that ships with
the toolchain.

- Dan C.

In article <jbg57cFl3udU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 4/9/22 20:35, Arne Vajhøj wrote:
>> In that case I think most K&R C code should compile with ANSI C.
>
>Trivial programs, probably. I just tried to compile a couple pieces
>of the Ultrix-11 3.1 source with gcc and after over 100 warnings and
>4 errors in a 1000 line piece of code it just stops.

Compiling software written with intimiate knowledge of its 16bit
target platform on a modern 32- or 64- bit host? I'm not at all
surprised that doesn't compile out of the box.

Ultrix-11 probably does all sorts of type punning between
integers and pointers, and may declare "standard" functions
incompatibly with respect to their modern definitions.

- Dan C.

In article <t2qm09$121c$1@gioia.aioe.org>,
chris <chris-nospam@tridac.net> wrote:
>On 04/08/22 13:26, Dan Cross wrote:
> [snip]
>>>> 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.
>
>Now we have it: Perhaps you are pre conditioned by the idea
>that vms is a dinosaur that has no place in "modern
>computing" ?. Far from it, may have had a difficult time with
>HP, but a robust os still in wide use and under active
>development.

No, now we have you putting words in my mouth. I like VMS. I
still run VMS on Alpha at home. We're talking about languages
here.

>>>> 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?
>
>Well, "better" is subjective. If you have a system that
>produces results, why does it need to be fixed ?. Use a wide
>variety of tools for clients, various ide's scripting and more,
>but still wedded to an ancient editor and makefile environment
>for my own work.
>
>You seem to be suggesting that those who value proven but
>not leading edge development methods are somehow deficient. If so,
>expect a response.Rants about Head in sand attitudes don't
>help either.

Reevaluating technical decisions in the light of changing
context is almost never a wasted exercise. Hardware changes
over time, the scope and complexity of problems changes, some
things that were critical become irrelevant and some that
irrelevant become critical.

I've seen some pretty profound changes over the last 30 years,
even in the "process": things like automated testing frameworks
were considered weird back then, now they're assumed.

>If you want to be an evangelist for rust, good for you, but
>sorry, just suspicious of salesman of any kind, however good
>the product. Far from mainstream and proven so far, even
>though it's been around for (what did you say ?) 10+ years,
>suggests it's not a great hit anywhere.

I have no desire to be an "evangelist" for any technology; one
of the things I've learned is that that's not useful. I use
Rust because I think it sits at a local maximum for the sorts of
work that I do; if something better comes along, I'll look into
that.

But, when a bunch of the grousing from those who don't actually
know much about the langauge is just wrong, it seems prudent to
correct the technical record.

>> 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."
>
>Some sections of society these days seem to think rewarding failure
>a good idea, but not everyone would agree. Good programming is not
>about language or tools, but an attitude of mind, like all professional
>work. That's what I was trying to get across...

Learning how to fail gracefully is a useful thing in general in
life.

Your attitude appears to be predicated on some notion of
"freedom" given to you by your tools. As others have pointed
out, arguing for the "freedom" to write bad code is not very
professional.

- Dan C.

- Dan C.

In article <t2q8jm$334$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>Yes, it is. I included it because it was one of the first articles
>Google returned to me when I did a search for Rust language articles.

I can tell you with some assurance that those results tend to be
different for different people.

>To go back to one of the examples I posted recently (which I picked at
>random from a list of Rust CVEs):
>
>https://rustsec.org/advisories/RUSTSEC-2020-0148.html
>
>|Affected versions of this crate have the following issues:
>|
>|Ptr implements Send and Sync for all types, this can lead to data races by
>|sending non-thread safe types across threads.
>|
>
>Avoiding data races is advertised as a core feature of Rust and this
>library managed to violate that rule.

Yes, and this library uses `unsafe` trait impls to violate the
core guarantees that give data race freedom: the semantics of
`Send` and `Sync`. These are what let you do things like
trivially send values like `5` between threads. If you abuse
those in an unsafe manner you can't claim that your code is
data race free anymore.

>|Ptr::get violates mutable alias rules by returning multiple mutable
>|references to the same object.
>
>_This_ violates the core feature of Rust which is the borrow checker.

Actually, no, it doesn't: note that the code in question uses
`unsafe` to manufacture mutable _references_ from a raw pointer
contained inside the object in question. This is one reason why
indirecting a raw pointer is _always_ unsafe.

>|Ptr::write uses non-atomic writes to the underlying pointer. This means
>|that when used across threads it can lead to data races.
>
>Another data races problem.

Another `unsafe` violation of the language's semantics.

>I'd call the above examples of the complete bypassing of Rust's unique
>features. And it doesn't even matter how they did it. What matters is
>that they did.

You might, but that's because bluntly, you neither know nor
understand the language.

>Just this one CVE shows the borrow checker being bypassed and the
>eliminating data races feature of Rust also being bypassed.

No it does not. That you assert that it does shows that you
neither know what the borrow checker is nor what it purports to
do.

>I also posted another example of a traditional buffer overflow issue.
>
>I would call this all memory safety being disabled, so no, it's not
>my imagination.

"Programmer writes bad library; creates bugs. Film at 11!"

>Would be nice if those articles pointed that out instead of gushing
>over Rust in the same way as people did over Java in the early days.

This I agree with.

- Dan C.