On 1/25/19, Jonathan Wakely <jwakely....@gmail.com> wrote:
> 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?
--good idea. I thought I wasn't allowed to do that... but tried it
and I am allowed
and it worked. Thanks.
--
Warren D. Smith
http://RangeVoting.org <-- add your endorsement (by clicking
"endorse" as 1st step)
