Const warning? (was: Re: [Patch] More redundant...)

[Gawain Bolton]

I'm glad to hear that there may already be a patch to have a "const" 
warning!  I can certainly see that pointers to pointers to pointers etc. 
would be more difficult to do, especially since const can be at any level.

To me, it is certainly worth having a warning if it can result in faster 
compile times and/or better code being generated.

As Paolo says, ideally the compiler would be able to generate the same 
code whether variables are marked const or not.  However, this is maybe 
not realistic.  So maybe it would just be a good idea to encourage use 
of const to save the compiler from having to do all the analysis to 
determine that a variable is const.


Gawain

Kaveh R. Ghazi wrote:

> > [discussion moved to gcc]
> > 
> > Gawain Bolton wrote:
> > 
> > 
> > These patches to add "const" make me wonder if the compiler couldn't
> > help us.
> > 
> > I thinking about a warning for variables which the compiler can see
> > are not modified. Something like:
> > 
> > Warning: Variable x should be const.
> > 
> > Is this possible? Could this be useful? 
> > 
> > Hi Gawain (by the way those patches mainly remove some NULL pointer
> > checks, only secondarily const-ify variables).
> > 
> > I find your question interesting: as for many other warnings of this
> > kind (unreachable code, uninitialized variables, and so on) how many
> > such warnings would be missed or spuriously emitted would constitute a
> > good testbed for the optimizers of the compiler. Ideally the code
> > generated would be identical with and without const qualifiers but we
> > all know that in the real world this is not the case!
> > 
> > Ideas from the compiler people???
> > Paolo.
>
>I once toyed with a patch to warn about variables that could be
>constified.  It worked fine for regular objects, but the hard part
>(for me at least) was pointers.  E.g:
>
> > char *****foo;
> > ***foo = bar;
>
>Getting it to understand and mark which of the pointer layers could be
>constified and which couldn't was beyond my abilities.  It's probably
>not hard for someone who understands how these trees are constructed.
>
>Note fixing it for pointers is important for finding large statically
>initialized data and sticking it in .rodata sections.
>
>If someone is interested in carrying this across the goal-line, I can
>try and dig it up.
>
>		--Kaveh
>--
>Kaveh R. Ghazi			ghazi@caip.rutgers.edu
>
>
>  
>