Hi there!
A little bit earlier I posted a code snippet to this e-mail thread with
"Foo**" -> "const Foo * const * const" conversion example:
"
// PRE-CONDITION: ...
// POST-CONDITION: ...
// INVARIANT: array 'arg' and all its elements won't be changed
void subfunc(struct zzz const * const * const arg) {
if (arg != NULL) {
printf("%s", "Done!");
}
}
void func(struct zzz ** arr_of_ptr, unsigned count) {
subfunc((struct zzz const * const * const)arr_of_ptr); // ОК!
subfunc(arr_of_ptr); // CLANG: x86-64 clang (trunk) -
WARNING!!!
// GCC: x86-64 gcc (trunk) - ERROR!!!
// INTEL: x86-64 icc 2021.10.0 - OK!!!
// MICROSOFT(c++?): x64 msvc v19.latest - OK!!!
// POWER64 GCC trunk - ERROR!!!
// ARM gcc(trunk) - ERROR!!!
// NOTE: based on godbolt.org
}".
This is how explicit conversion looks like - "subfunc((struct zzz const *
const * const)arr_of_ptr);".
Per me, it is awful and makes the code less readable.
Another important thing about C is minimalism. We always try to make an
application as simple and short as possible to provide all the necessary
functionality.
Explicit casts actually is not C style, unless you're not doing something
with "void*".
It is more about C++ :(
Respectfully,
Aleksandr G Povaliaev.
пн, 8 дек. 2025 г. в 00:08, Segher Boessenkool <[email protected]>:
> 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.
>
> 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.
>
> > 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.
>
> Explicit casts are exceptional, and that is how they should be used.
> Whenever you see one, you know something unusual is going on. Implicit
> casts can be treacherous that way (but they are prefered often). Good
> taste cannot be taught, all that.
>
> (This is assuming you're looking at reasonable code of course. Oh
> well).
>
>
> Segher
>
