On Thu, Jul 19, 2012 at 12:47:21PM +0200, Paolo Carlini wrote:
> On 07/18/2012 02:40 PM, Jakub Jelinek wrote:
> >The problem on the GCC side is that both the C and C++ FEs fold away the
> >sizeof too early (well, C++ FE only when not in a template, otherwise
> >SIZEOF_EXPR is created and guess one could tsubst its argument again).
> >I've only done C FE right now, instead of constructing SIZEOF_EXPR always
> >and folding it later on (which would be much more work and could risk
> >regressions) I'm just remembering the last sizeof argument which is all that
> >is needed for this kind of warning (yeah, admit not very nice, but works).
> >For C++ I guess similar spot could be finish_call_expr (adding another
> >argument, usually NULL, to it) that would be feeded by remembered last sizeof
> >argument or during tsubst from SIZEOF_EXPR argument after tsubsting.
> I have a couple of random comments. About the folding, I'm wondering
> if our current behavior is causing actual bugs (similarly to, eg,
> all the issues we have with arrays decaying to pointers too early).
I don't think it causes any issues appart from making it harder to do static
analysis. On the C FE side I can still imagine emitting SIZEOF_EXPR always
and only folding that during c_fully_fold_internal, but I don't see anything
similar on the C++ FE side, and there we often rely on the folding of
various things say for template parameters and what not else.
For processing_template_decl I believe it is fairly easily implementable,
but for !processing_template_decl I currently don't see an easy way to avoid
the hack I wrote for the C FE. Jason?
> Otherwise, the implementation of the warning itself seems to me a
> little ad hoc indeed, but simple enough.
Also the c-family/ part of it, or just the c/ part? The latter I admit is
not very nice (another ugliness is that we want the parameters before doing
standard argument promotions on them).
> Unrelated, but I can't resist, it would be great if for 4.8 we could
> also eliminate the duplicate diagnostics noticed in 28656, does that
> look doable?!? If you have hints I could also do it, in practice.
The problem there is that memcpy (and I guess many others) ends up with more
than one nonnull attribute. Untested patch in the PR now.
Jakub
