This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

"const"-related gcc warnings with pointers around, annoying


"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.



-- 
Warren D. Smith
http://RangeVoting.org  <-- add your endorsement (by clicking
"endorse" as 1st step)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]