On 29/02/2024 12:29, Malcolm McLean wrote:
On 28/02/2024 12:48, Thiago Adams wrote:
The C Standard charter
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3223.pdf
C99
Trust the programmer.
C11 added
"12. Trust the programmer, as a goal, is outdated in respect to the
security and safety programming communities. While it should not be
totally disregarded as a facet of the spirit of C, the C11 version of
the C Standard should take into account that programmers need the
ability to check their work. "
So it's portable assembler, and if you are writing in assembly, you can
walk all over that machine and do pretty much what you want, if you
can't do that it's not assembly, and that is part of the point of it,
but the main point usually is to be very fast, and it is a risk that you
want to avoid, but it's almost but not quite inherent to it, and if you
try to put checks in you'll make things very much more complicated. And
so maybe it must still be "trust the programmer".
Your logic is muddled.
No, you can't "walk all over that machine" even in assembly. But there
are certainly fewer limits to what you can do from assembly.
No, C is not - and never has been - "portable assembler". No, you can't
"walk all over that machine" in C, even if it "trusts the programmer".
No, trusting the programmer does not make something "assembler".
But yes, "trust the programmer" is part of making things fast and efficient.
C23
"15. Application Programming Interfaces (APIs) should be
self-documenting when possible. In particular, the order of parameters
in function declarations should be arranged such that the size of an
array appears before the array. The purpose is to allow
Variable-Length Array (VLA) notation to be used. This not only makes
the code's purpose clearer to human readers, but also makes static
analysis easier. Any new APIs added to the Standard should take this
into consideration. "
This is indirectly about safety.
So now you must write payroll(N, employees), and that's perfectly understandable. But it's more natural to write payroll(employees, N),
and that makes it a bit easier to read, and we're meeting the needs of
the machine and not the programmer, and it's really not a good direction.
Some people prefer one way, others prefer a different way - what is
"natural" to you (or to me) is no basis for judging what is "natural" to
anyone else.
And no, nothing about this changes what /you/ have to write. You make
your own choices in your own code. Nor does this suggestion change any existing standard library functions.
It simply means that if there is a function that requires an array, with parameters being a pointer to the start of the array and a count of the elements, then the committee sees advantages in declaring it :
int foo(size_t n, int data[n]);
rather than
int foo(int * data, size_t n);
This is nothing new, nothing dramatic, already used in a lot of existing
C functions, and given as examples in previous C standards.
C2Y (more stuff)
"Enable safe programming
The language should take into account that programmers need the
ability to check their work.
While not guaranteeing program correctness, properties such as
portability, unambiguity,
memory safety, type safety, thread safety, etc. are prerequisite to
reasoning about security and
reliability. Software interfaces should be analyzable and verifiable.
The language should allow
programmers to write concise, understandable, and readable code."
And so maybe this is going to help a bit, but it's not the underlying
reason most software projects fail.
"Enable functional safety
C is frequently used in the development of safety-critical systems.
Functional safety is the
systematic process used to analyze that a fault does not prevent a
program from performing its
required function. An analyzable subset of the language is used to
create a safety argument;
this subset should be enlarged. Unbounded undefined behaviors (that
represent a single point
of failure) should be eliminated."
And in reality UB in C is almost a post error leading to an out of
bounds array access. And maybe, just maybe, that is the thing to try to
fix and change. But you can't do that by banning pointers, and you've
got to it by making pointers carry around bounds infotmation, and that
is going to be a big change.
I think you are mixing things up and failing to say what you had
intended - but I believe hidden in there you have a point.
The idea of Annex L "Analyzability" is to try to distinguish between
"bounded undefined behaviour" that might not be /too/ bad and for which recovery might be possible, and "critical undefined behaviour" that can
include things like stomping on other data. Trying to find a way to
limit the consequences of errors is a good thing - but I don't believe
it is possible in C, and I don't think Annex L is of significant use to
anyone here. And even it were, any mistake - even if it is "bounded" -
can lead to consequences that result in critical errors.
The principles intended to guide the committee are changing from
"thrust the programmer" to "enable safe programming".
I think this is a good thing and I expect the next release to be much
safer.
What do you think?
And you can't enable safe programming can you? All you can do is make it
a bit more difficult to do risky programing.
You /can/ allow tools to do a better job of supporting safe programming
or better checking (at compile time or run time). Ironically, one of
the advantages of undefined behaviour is that it means compilers can add run-time checks (such as "sanitizers") for problems - if things like dereferencing null pointers or signed integer overflows were defined
behaviour, this would not be possible.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)