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

[Titus von Boxberg]

Am 13.07.2011 um 11:13 schrieb Peter Geoghegan:

> On 13 July 2011 01:06, Nico Weber <thakis at chromium.org> wrote:
>> In the past, warnings that warns about a common pattern but also find
>> bugs have been kept on-by-default. Search this list for
>> -Wdelete-non-virtual-dtor.
> 
> I don't have time to review Clang's exact behavior there right now,
> but my guess is that this is a false equivalency. Code that causes
> that warning at the class definition (which I think is what you allude
> to - no delete is required) is inherently wrong according to the C++
> intelligentsia, unless the base dtor is declared protected per an
> idiom described by Herb Sutter. No one would ever encourage virtual
> functions with a non-virtual public dtor (some styleguides go so far
> as to require all dtors be virtual, which even the std lib violates),
> whereas what I describe is in various text books.
> 
>> This bug is in ICU, which is pretty commonly used. Someone (me) posted
>> an example where this warning found a bug within 2h of Chris asking
>> for it, so maybe it's not as vanishingly small as you think.
> 
> That bug was really obvious, and was a narrow case of someone misusing
> a struct that used this idiom. I doubt the developer of that app would
> thank you for your attitude - you just saved them this one bug, but
> you probably created a whole bunch of spurious warnings at other parts
> of their codebase in the process. Why should they even think that it's
> valid in this one place anyway, where it is only valid by dumb luck?
> They weren't clued-in enough to catch a really obvious bug in the
> first place.
> 
> On 13 July 2011 04:39, Chris Lattner <clattner at apple.com> wrote:
> 
>> -Warray-bounds-single-element seems like overkill to me, but is completely feasible.
> 
> Right. Let the extremely paranoid individuals (avionics engineers,
> medical equipment engineers) throw every single flag that produces
> additional warnings at Clang, which they're quite happy to do their
> homework on. Let the vast majority of developers have sane,
> non-annoying behaviour without any burden to pass additional flags.

A small meta comment:
Your complaints would be less annyoing to read if you'd
stop using cheap rhetorical tricks like displaying your use case 
as "sane", "reasonable", representing the "vast majority", etc.;
and others as "paranoid", "burdened with passing additional compiler flags"
(WOW! that's something I have to remember as a nifty excuse for the next time the
delivery date is missed! Sorry, I was so burdened passing all the additional
compiler flags, really, I couldn't make it!
sorry, I'm using cheap rhetorical tricks ;-),
"gross", "unhygienic" etc.

But, alas!, speaking as a "paranoid avionics engineer", being expected
to happily carry the compiler flag burden home with me, I can only recommend being
compliant with latest language standards, in this case C99.
Shouldn't be too bad for postgresql to target a now
already aging standard.
Also the software I'm working on suffered some from some non-standard
extensions that we took as granted, but were marked as an error or were
given a warning by clang.

So, I did not see an argument why using the "unhygienic" suggestion
of C99 variable length arrays isn't viable; if MS cl.exe does not support
this (which I don't know), I'd see this as an insufficient standards
implementation and regard this as the problem of this compiler, not of clang.
In this case, I'd recommend to use the "gross" suggestion of Reid Kleckner.
This is analogous to what e.g. boost does for portability to older non
compliant compilers, and in most cases I wouldn't attribute the boost libs
with any of the fancy negative words you brought up so far.
And I'd regard the fact that this expression of the idiom
is - as Reid pointed out - self-documenting as adhering to very high hygienic
standards.

Regards
Titus