On Sun, 12 Dec 2021, Abramo Bagnara wrote:
That's certainly better. And this provides you with the opportunity toWho in its right mind will believe that sprinkling typecasts aroundIn the specific, double casts are needed in two situations:
document the reason for such a macro alongside its definition.
2) A narrower computation is assigned to a wider or differentlyWell, you aren't preventing any wrapping by adding a bunch of casts.
Of course, if we want an unsigned 64-bit addition, we should writeOr even:
u64 = u32_a;
u64 += u32_b;
Two lines, but still more enjoyable to read.
Again, it is possible to encapsulate the cast used to express theOnly if that was the actual intent.
I doubt such thing was deliberate. Most likely a value wrap is just not
a possible outcome ever in a given code context and no one deemed it
necessary to explicitly spell such thing out.
Assigning to an u64 is indeed a bit suspicious in such a case. Maybe the
u64 is unnecessary to start with, and if so that's what needs fixing
whereas papering over it with a cast pipeline doesn't improve the code.
Here I disagree.Why do we have to make all loop index vars unsigned? It is a very commons32 < 0U and s32 < 0 makes a *lot* of difference: this is one of the
s32 < 5U is wrong.
s32 < 5 is OK
u32 < 5U is OK
u32 < 5 is OK
So the unqualified literal is less cluttered, and always OK.
The qualified 5U is ugly, and wrong in mixed signedness cases.
So the safest thing to do, and the most convivial for developers and
reviewers alike, is to _NOT_ qualify literals as unsigned by default.
The signed/unsigned semantic is already carried by variables those
literals are used with.
We might consider deviating for signed constants whose value is unchanged byThat would be an improvement indeed.
OK.And why casting pointer difference to a size_t? The official type for aActually, a standard C implementation must ensure that the maximum
But still, what's the point? Just to get rid of the signed nature of it?
Because it is not returning a boolean. It is returning a non-zero valueAnd a real kicker is this change:Here I really don't follow you: if the function was *already* returning
on failure. That's not a boolean. The common operating system idiom in
that case is to return an error code, typically negative.
If the particular error reason is unnecessary then it is of course a
valid simplification to return a boolean instead. But it should be true
for success and false for failure which is by far the most common
expectation. And then the name of the function should probably be
modified as well to make it clear to users that the function is no
longer following the error code return paradigm. Otherwise it is best to
leave it as is.
Nonetheless I think that the right mindset is that missing adherenceI think both cases should be justified carefully. Some rules might have
been justified back when people wrote C code K&R style but are just an
annoyance with no real benefit nowdays.
I've also seen too many times a bug being introduced because the code
was modified just to make it [name your favorite static analysis tool /
coding standard here]-compliant. It is often the case that the code is
questionnably written in the first place, and adding typecasts to it
makes it worse even if the scanning tool is then happy.