Re: A: a new bug to old plain C

On 07/12/2025 22:08, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Dec 07, 2025 at 11:39:59AM -0800, Andrey Tarasevich via Gcc-help wrote:
>> In order to signal the compiler that "you clearly understand what you are doing"
>> in this particular situation you have to use an explicit cast.

Yes.  Casts should be, for most kinds of programming, an unusual 
construct.  The intention for implicit conversions in the design of the 
C language is that conversions that are safe are implicit, conversions 
that may be risky are explicit.  Unfortunately C does not live up to 
that ideal, failing in both directions, but usually casts are an "I know 
what I am doing" indicator.

(An exception, perhaps, is when programming for small embedded systems 
where you might have significant use of arithmetic on types that are 
smaller than "int" on some systems.  There you might prefer explicit 
casts on data to be sure you are getting the right signed or unsigned 
and size when the integer promotion rules could give different results 
on different targets.)

> 
> The best way (or the only way really) is to not use a compiled language
> at all, but to use machine code instead, or *maybe* assembler language.
> 

When used correctly, casts are perfectly safe in C.  (Incorrect usage is 
another matter, of course.)  Assembly will not do the job of a cast - it 
does not make sense to have a type conversion in a typeless language.

(And why do you say "machine code, or *maybe* assembly language" ? 
There are some assembers and assembly language where the correspondence 
between assembly and machine language instructions is not exactly 
one-to-one, but it is always very close and very well defined.)

>> There are lots and lots of
>> conversions in C that are only available through _explicit_ _casts_
> 
> Where "lots and lots" means "exactly zero": you can always do an
> ssignment to something with an appropriate type.
> 

Um, no.  There are very few situations where the conversion of a value 
of type U requires a cast to convert it to type V, and where you can 
avoid the cast by using assignments.

The only case I can think of is converting between incompatible pointer 
types via assignment to a temporary void* pointer.  And doing that is, 
IMHO, a far worse option than a cast, where at least it is clear and 
explicit that you are playing with fire.  Faffing around with pointer 
casts is a good way to introduce "but it worked when I tested it!" 
undefined behaviour and bugs into your code.  Doing so via void* just 
hides the problem.

> Explicit casts are exceptional, and that is how they should be used.

Yes.

But "exceptional" does not mean they are not a useful language feature, 
and it does not mean that they should be avoided when they are useful or 
necessary, and it certainly does not mean you should try to find 
convoluted workarounds (like using a different language!) to avoid them.

> Whenever you see one, you know something unusual is going on.  Implicit
> casts can be treacherous that way (but they are prefered often).  

Yes.

> Good
> taste cannot be taught, all that.
> 

Good style can certainly be taught.  And good style is context-dependent 
- what is considered "good style" for one kind of project or programming 
task may be very different from the style of a different kind of task.

> (This is assuming you're looking at reasonable code of course.  Oh
> well).
> 
> 
> Segher
>