[cfe-dev] -Warray-bounds seems over-zealous on Clang

David Blaikie dblaikie at gmail.com
Wed Jul 13 08:05:13 PDT 2011

On Tue, Jul 12, 2011 at 4:59 PM, Peter Geoghegan <peter at 2ndquadrant.com>wrote:

> On 13 July 2011 00:28, David Blaikie <dblaikie at gmail.com> wrote:
> > I think someone mentioned the idea of adding a separate warning for this
> > narrower case and, in the case of compiling for c99, suggesting a fixup
> of
> > using a flexible array. In the case of c89 at least it'd be a separate
> > warning that, if the pattern is used extensively in the codebase, could
> be
> > disabled separately from the more general warning (which would be
> adjusted
> > to ignore these cases).
> >
> > This would allow for the bug that was mentioned to have been found, while
> > allowing you to disable this warning if you don't think the chance of
> such
> > bugs coming up is worth the code hygiene cost of the above construct or
> the
> > move to c99 would be worthwhile in your case.
> While strictly speaking that would be a valid solution, it would also
> be overly-complex considering the benefits IMHO. I'd now have a flag
> to pass to Clang, but only to Clang, despite the fact that it's
> supposed to be a drop-in replacement for GCC. I'd now have to
> explicitly indicate that I was using C89.

If you are compiling c89, that doesn't seem onerous - perhaps one day GCC
could get smarter & start warning you about this or other superseded
constructs if you continue to compile as c99 but avoid c99 features.

So, options that seem to be being discussed include:

1) suppress this warning in all cases where the array is of length 1 and the
last element in a struct
  1.1) refinement: only when the length is specified explicitly and not via
macro expansion, etc. (as John suggested)
  1.2) refinement: under c99 recommend a fixup to use flexible arrays
2) split the warning in two, the second being the cases suppressed by the
above option (probably less interesting if 1.1 is implemented)

> Once again, the burden would be on application developers who are just
> using a demonstrably mainstream idiom,

Mainstream in c89 with better alternatives in c99.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110713/2a99829e/attachment.html>

More information about the cfe-dev mailing list