On Fri, 25 Jan 2019 at 13:48, Warren D Smith <warren....@gmail.com> wrote:
>
> "foo" is a type that is a struct containing a uint64_t field x[4]
> (among other things).
>
> bool Proc( const foo *dog ){
> uint64_t *a, *b;
> a = dog->x; // pointer a now points to dog->x[0]
> b = something else;
> if( *a == *b ) return(TRUE);
> return(FALSE);
> }
>
> Now gcc complains
> warning: assigning to 'uint64_t *' (aka 'unsigned long long *') from
> 'uint64_t const[4]' discards qualifiers
> [-Wincompatible-pointer-types-discards-qualifiers]
>
> but the thing is, those pointers a and b, never got used to alter
> anything. They merely
> were used to read harmlessly from memory. So dog still clearly was never
> altered, and hence genuinely was const.
>
> The problem here seems to me to be a lack of intelligence inside gcc's
> thinking on the subject of "const"s. Sure assigning to a pointer
> could be harmful to const-hood because
> that pointer could get used someplace else to write to the "const" part of
> memory. BUT, if we know that pointer never can be used to write
> to memory anywhere, because it lives only inside the restricted scope of
> Proc(){}, and never is used to write to memory anywhere, and never is
> copied to any
> other variable (because we examine the code inside Proc to verify
> this), then it was
> ok and gcc should not warn.
This belongs on the gcc-help list, not here. If you want changes to
GCC's diagnostics please file a bug report in Bugzilla.
Basically you're asking for GCC to do escape analysis on the converted
pointer, and suppress the warnings if it doesn't escape and no stores
are done through the pointer.
I think it would have to be an optional behaviour for the warning,
because some people *do* want that warning. Maybe the pointer doesn't
escape today, but the code could change tomorrow, and they'd want to
be warned about the discarded qualifiers today.
Also, if the pointer's scope is strictly limited to that function, and
you never write through it, why not just make it const? What is the
advantage of writing your code that way, and requiring changes to the
compiler to deal with your desire to ignore the const qualifiers?
