Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Code guidelines
Date: Wed, 4 Sep 2024 08:52:31 -0300
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <vb9hlv$3qa2u$1@dont-email.me>
References: <vb6v1t$3b5mb$1@dont-email.me> <vb726n$3b4rq$1@dont-email.me>
 <vb736j$3b5mb$2@dont-email.me> <vb75g9$3bntp$1@dont-email.me>
 <vb77tn$3bu07$3@dont-email.me> <vb7d6l$3d5mv$1@dont-email.me>
 <vb7dve$3d5mv$2@dont-email.me> <vb8vlv$3nlvo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 13:52:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1faf17ca17b4b674f1c33ee4dfab027e";
	logging-data="4008030"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OyDBwSqLLwqRy+gDJ+33+G77hg95COTk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:KSWrMW3KgC6lKlcXkFIozY44hzg=
Content-Language: en-US
In-Reply-To: <vb8vlv$3nlvo$1@dont-email.me>
Bytes: 4544

On 04/09/2024 03:45, David Brown wrote:
> On 03/09/2024 18:37, Thiago Adams wrote:
> 
>>
>> I also have a interesting sample with linked list
>>
> 
> Speaking generally rather than specifically about this code, your extra 
> checks are redundant when the code is run from a single thread, and 
> insufficient if it is later used from multiple threads (accessing the 
> same data).  But extra checks can fool people into thinking it is safe - 
> since the checks are unnecessary for sequential code they must have been 
> put there to catch rare race conditions.
> 
> 
> There are times when you want seat-belts /and/ airbags.  But focusing on 
> that instead of making sure the driver is competent is not helpful!
> 
> 
> 



In Cake (my front-end), I made `assert` a special built-in function to 
allow it to be used by static analysis.

For instance:

`assert(p != 0);`

Static analysis will then assume that `p` is not zero after this line.

However, this raises a question:
Does assert overrides what the compiler already knows?

For example:

int i = 1;
assert(i == 2);

Here, the compiler knows `i` is `1`, but the `assert` (i.e., the 
programmer) is claiming that it’s `2`!

I then reconsidered my view. `Assert` is about what the programmer is 
stating to be true. (Programmer can be wrong) It is not a "override 
command".

I think this is applicable for any "assume concept".

C++ 23 added [[assume( expression )]] 		

"Tells the compiler to assume that an expression will always evaluate to 
true at a given point ..." "The purpose of an assumption is to allow 
compiler optimizations based on the information given"

There is a big warning there :
"IMPORTANT: DANGEROUS OPERATION, USE WITH CARE"

https://en.cppreference.com/w/cpp/language/attributes/assume

I also may add this [[assume]] to cake, but assert also gives me a 
runtime check.

In the first example `assert(p != 0)`, the compiler knows that `p` is 
MAYBE `null`. But the programmer is asserting that `p` cannot be `null`, 
so the compiler will follow the programmer's assertion.

Perhaps the programmer knows something the compiler doesn’t?

This is similar to a case with a linked list, where the programmer knew 
that if the `head` is `null`, then the `tail` must also be `null`.

However, if the compiler is certain about a fact and encounters an 
`assert` with conflicting information, it should trigger a warning.

For example:

int i = 0;
assert(i != 0); // Warning



When the compiler finds an assert, that is not adding extra information 
but only saying what the compiler already knows, then we don't have 
warnings. But, this is a redundant check.

int i = 0;
assert(i == 0); // ok

On the other hand, redundant 'if' I have a warning.
if (i == 0) {} //warning 'i' is always 0 here!

So, basically.
- if assert has a conflicting information compared with what compiler 
already knows, then it is a warning. Compiler will not override what it 
knows?

- If the assert gives the exactly information compiler already have, 
then is is not a warning. Both compiler and programmers knows the same 
thing.

- If the compiler is not sure about a fact and the programmer gives a 
plausible fact then the compiler will assume the programmer is correct.