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

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.

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

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

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?

On Wed, 28 Feb 2024 09:48:40 -0300, Thiago Adams wrote:

>
>The C Standard charter
>https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3223.pdf
>
>C99
> Trust the programmer.
>

>What do you think?
>

if the types have all know size, and function or operation are well
defined on these, it is possible write a portable program that in each
sys from the same input return the same output

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

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

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

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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.