A: a new bug to old plain C

Александр Поваляев apovalyaev@gmail.com
Tue Nov 25 16:09:19 GMT 2025


Hi there!

My code snippet which we're discussing was written in accordance with the
code safety recommendations provided by your colleagues :)
So, the code snipped is naturally doing what was recommended in that C FAQ:
we're converting "Foo**" to "const Foo * const *" to avoid the possible
const-violations.

Here is a note from some recommendation which has been provided by your
colleagues (
https://isocpp.org/wiki/faq/const-correctness#constptrptr-conversion) :
"The rationale for why that error is a good thing is given below. But
first, here is the most common solution: *simply change **const
Foo** to const Foo* const**"
And we are NOT converting "Foo**" to "const Foo**", we ARE converting
"Foo**" to "const Foo * const * const".
Please pay some more attention to what I am writing here.

Then one more "const" is added since it is going to change neither the
value which the variable is pointing to nor the value of the variable
itself, since it denotes "end-of-loop iteration".
Please, read carefully the use-case which I provided at the very beginning
of this e-mail thread. Here it is:
"
struct zzz const * const * const end_of_arr = arr_of_ptr + count;
"
And it should work fine. Since it is written in all the recommendations and
in accordance to C standard.
Nobody and no place and no recommendation forbid us from converting "Foo**"
to "const Foo * const * const".
So, since it is allowed by C standard, it should work fine with all the GCC
toolchains.
But with some of them, some of GCC toolchains (like GCC ARM trunk linux) it
doesn't.
So, it should be fixed.

Respectfully,
Aleksandr G Povaliaev.



вт, 25 нояб. 2025 г. в 14:58, Matthias Pfaller <leo@marco.de>:

> As several people already pointed out to you, this is not a bug in the
> compiler. Your code is valid with C++, but invalid with C.  Is this so hard
> to understand? What you do is just like insisting on
>
> void f(int *);
> void nonsense(void)
> {
>   register int x;
>   f(&x);
> }
>
> to be valid C code. It might look ok, but it's still invalid code.
>
> On 2025-11-25 12:28, Александр Поваляев wrote:
>
> Hi there!
>
> Yes.
> Here is the original message from myself: "
> struct zzz {
> unsigned x, y;
> };
> void square(struct zzz ** arr_of_ptr, unsigned count) {
> *// The first "const" produce an error (not a warning) within some GCC
> toolchains, for example ARM GCC trunk (linux), see goldbolt.org
> <http://goldbolt.org>*
> struct zzz const * const * const end_of_arr = arr_of_ptr + count;
> *// Without the first const "struct zzz * const * const end_of_arr =
> arr_of_ptr + count;" it works fine!!!*
> }
> ".
>
> So, somebody made this BUG to some GCC toolchains (ARM GCC trunk(linux)
> and some others). We need to have it nailed down and fixed somehow.
>
> Respectfully,
> Aleksandr G Povaliev.
>
>
> вт, 25 нояб. 2025 г. в 13:32, Matthias Pfaller <leo@marco.de>:
>
>> You are aware, that you are quoting the C++-FAQ? Aren't we talking about
>> C?
>>
>> Congratulations btw, you are (I think) the first person managing to
>> exhaust
>> Jonathan's patience. I always thought he had a limitless source of
>> patience hidden
>> somewhere and envied him for it...
>>
>> On 2025-11-25 11:24, Александр Поваляев via Gcc-help wrote:
>> > We're not converting "Foo** -> const Foo**". We are doing "Foo** ->
>> const
>> > Foo * const * const" conversion and this works fine (according to the
>> right
>> > the same
>> > https://isocpp.org/wiki/faq/const-correctness#constptrptr-conversion
>> which
>> > was mentioned).
>> >
>> > So, what we're doing is correct from both language syntax and coding
>> > practices (safe coding) points of view.
>> > This bug should be reported and fixed!!!
>> >
>> > Respectfully,
>> > Aleksandr G Povaliaev.
>> >
>> > пн, 24 нояб. 2025 г. в 20:49, Henrik Holst <
>> henrik.holst@millistream.com>:
>> >
>> >> no they are not, they are a WIKIfication of the C specification, in
>> >> particular the heading "Why am I getting an error converting a Foo** →
>> >> const Foo**?" in an official FAQ from the C Standards Committee should
>> make
>> >> you realize this.
>> >>
>> >> /HH
>> >>
>> >> Den mån 24 nov. 2025 kl 18:45 skrev Александр Поваляев <
>> >> apovalyaev@gmail.com>:
>> >>
>> >>> The articles mentioned are all about coding practices ("safe" and
>> >>> "unsafe"). They are not about bugs in compilers and hard restrictions
>> being
>> >>> placed on where I can use "const" in my code and where I can't. :)
>> >>>
>> >>> The links mentioned earlier just give a recommendation to use "Foo**
>> ->
>> >>> const Foo * const *" conversion instead of "Foo** -> const Foo**".
>> >>> Literally, what I am saying is that: "if you can use const, you should
>> >>> use it". And this is the case which just confirms my attitude.
>> >>> But again, this is about coding practices and recommendations. There
>> is
>> >>> no place in C and C++ standards saying "DON"T USE CONST EVEN IF YOU
>> CAN DO
>> >>> IT. WE'RE PROHIBITING THIS".
>> >>>
>> >>> And so, what GCC compiler (+ some SDKs) is doing now is just the
>> opposite
>> >>> to the recommendation mentioned. It restricts the places where "const"
>> >>> might be used.
>> >>> Anyway, it is a BUG (BIG BUG!!!) in the GCC + SDK. And the BUG was not
>> >>> made intentionally to protect software engineers from using "unsafe
>> coding
>> >>> practices" :)))))
>> >>> For such kind of practices, there are warnings with information
>> messages.
>> >>> And the bug in GCC should be (1) reported; (2) nailed down and (3)
>> fixed.
>> >>>
>> >>> Respectfully,
>> >>> Aleksandr G Povaliaev.
>> >>>
>> >>>
>> >>> пн, 24 нояб. 2025 г. в 16:10, Henrik Holst <
>> henrik.holst@millistream.com
>> >>>> :
>> >>>>
>> >>>> Den mån 24 nov. 2025 kl 13:40 skrev Александр Поваляев <
>> >>>> apovalyaev@gmail.com>:
>> >>>>
>> >>>>> Hi there!
>> >>>>>
>> >>>>> "False sense of security". Const is a hint to any C compiler to make
>> >>>>> code more error-prone. So, it is always better to use as much
>> "const" as
>> >>>>> possible.
>> >>>>> My point is that "if const might be used, it SHOULD be used". That
>> is
>> >>>>> the cornerstone.
>> >>>>> I want to use it, so GCC compiler + SDK should make it possible. It
>> is
>> >>>>> my code and my design decisions being undertaken.
>> >>>>>
>> >>>>> All discussions if it is possible to overcome or not "Const"
>> >>>>> restriction is irrelivant here.
>> >>>>>
>> >>>> no it is not irrelevant here because if I declare a variable as
>> const in
>> >>>> my local code the value should not be changed by other code either,
>> look at
>> >>>> the code in the link given to you earlier which shows just such a
>> case as
>> >>>> an example on why this is not allowed in C.
>> >>>>
>> >>>> /HH
>> >>>>
>> >>>>> Respectfully,
>> >>>>> Aleksandr G Povaliaev.
>> >>>>>
>> >>>>> пн, 24 нояб. 2025 г. в 13:46, Henrik Holst <
>> >>>>> henrik.holst@millistream.com>:
>> >>>>>
>> >>>>>> The things is that this is unsafe and invalid due to it creating a
>> >>>>>> false sense of security. Aka your "const Foo *" can change under
>> your feet
>> >>>>>> by _other_ code leading to your const here giving you a false
>> sense of
>> >>>>>> security. Yes it prevents you from modifying it locally but not
>> some other
>> >>>>>> code or thread from modifying your const pointer to now point to
>> something
>> >>>>>> else, hence the compiler issues an error here since you do not get
>> what you
>> >>>>>> think you are getting.
>> >>>>>>
>> >>>>>> /HH
>> >>>>>>
>> >>>>>> Den mån 24 nov. 2025 kl 11:10 skrev Александр Поваляев via
>> Gcc-help <
>> >>>>>> gcc-help@gcc.gnu.org>:
>> >>>>>>
>> >>>>>>> Hi there!
>> >>>>>>>
>> >>>>>>> The code is not invalid and neither of the links posted saying
>> that
>> >>>>>>> "const
>> >>>>>>> Foo * const * const" is invalid construction for C.
>> >>>>>>> The links posted just are discussing that it might be UNSAFE to
>> cast
>> >>>>>>> "Foo
>> >>>>>>> **" -> "const Foo **" and recommending usage of "Foo **" -> "const
>> >>>>>>> Foo *
>> >>>>>>> const *" instead.
>> >>>>>>> It's OK. If you feel that it is unsafe, please don't use it. It is
>> >>>>>>> your own
>> >>>>>>> decision.
>> >>>>>>>
>> >>>>>>> But the syntax itself "const Foo * const * const" is correct and
>> the
>> >>>>>>> use-case I mentioned is quite simple and evident.
>> >>>>>>> And so I need this code snipped to be compiled transparently over
>> all
>> >>>>>>> the
>> >>>>>>> GCC (and platform SDKs) available versions.
>> >>>>>>>
>> >>>>>>> Respectfully,
>> >>>>>>> Aleksandr G Povaliaev.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> пн, 24 нояб. 2025 г. в 01:48, David Brown <
>> david.brown@hesbynett.no>:
>> >>>>>>>
>> >>>>>>>> On 23/11/2025 21:45, Александр Поваляев via Gcc-help wrote:
>> >>>>>>>>> Hi there!
>> >>>>>>>>>
>> >>>>>>>> This is getting /extremely/ frustrating.  /Please/ find some way
>> to
>> >>>>>>>> learn the C programming language - courses, books, good online
>> >>>>>>> resources.
>> >>>>>>>> And /please/ believe me when I say that people who have worked
>> with
>> >>>>>>> C
>> >>>>>>>> and C++ for decades, studied the standards, who serve on the
>> >>>>>>> standards
>> >>>>>>>> committee, know better about these things than you do.  (I'm
>> talking
>> >>>>>>>> about Jonathan here, not myself - he really is a world-class
>> expert
>> >>>>>>> here.)
>> >>>>>>>>> Either the links you've provided or the links you provided
>> earlier
>> >>>>>>>>> (yesterday) are irrelevant, cause they are just discussing if it
>> >>>>>>> is safer
>> >>>>>>>>> to convert "Foo_Type **" to "const Foo_Type **" or not.
>> >>>>>>>>>
>> >>>>>>>> The links are highly relevant.  They explain why you cannot
>> convert
>> >>>>>>> from
>> >>>>>>>> "char **" to "const char **".  That also explains why you cannot
>> >>>>>>> convert
>> >>>>>>>> from "char **" to "const char * const * const".  Adding even more
>> >>>>>>>> "const" qualifiers to the invalid conversion does not somehow
>> >>>>>>> magically
>> >>>>>>>> make it work.
>> >>>>>>>>
>> >>>>>>>>> Once again, we are not converting "char** to const char**",
>> we're
>> >>>>>>>>> converting char** to const char * const * const".
>> >>>>>>>>> And we're not discussing if it is safer or not, we are
>> discussing
>> >>>>>>> GCC
>> >>>>>>>>> compiler error.
>> >>>>>>>>>
>> >>>>>>>> The compiler is generating an error message because you wrote
>> >>>>>>> invalid
>> >>>>>>>> code.  The error - or bug, if you like - is in /your/ code.  Not
>> the
>> >>>>>>>> compiler.  GCC is doing its job correctly here.
>> >>>>>>>>
>> >>>>>>>>> Respectfully,
>> >>>>>>>>> Aleksandr G Povaliaev.
>> >>>>>>>>>
>> >>>>>>>> I'm sorry, but signing the post with "respectfully" does not
>> make it
>> >>>>>>>> respectful.  You started the thread disrespectfully - insisting
>> that
>> >>>>>>>> there is a bug in GCC when you simply do not understand the
>> relevant
>> >>>>>>>> aspects of the C programming language.  And you have gone
>> downhill
>> >>>>>>> since
>> >>>>>>>> then, ignoring and rejecting the help and advice you have been
>> >>>>>>> given.
>> >>>>>>>> Getting things wrong once is entirely understandable - this is a
>> >>>>>>> subtle
>> >>>>>>>> point of the C language, and you are posting to a "help" list.
>> >>>>>>> Doubling
>> >>>>>>>> down on your ignorance when you have received the help and
>> >>>>>>> information
>> >>>>>>>> you need, is a different matter entirely.
>> >>>>>>>>
>> >>>>>>>> Your code is flawed.  You need to fix it.  Mindlessly repeating
>> your
>> >>>>>>>> misunderstandings about how you think C works will not do
>> anything
>> >>>>>>> but
>> >>>>>>>> annoy people.
>> >>>>>>>>
>> >>>>>>>> David
>> >>>>>>>>
>> >>>>>>>>
>>
>


More information about the Gcc-help mailing list