This is the mail archive of the
mailing list for the GCC project.
Re: Request for a C++ warning for undefined behaviour
- From: skaller <skaller at ozemail dot com dot au>
- To: Michael Matz <matz at suse dot de>
- Cc: gcc at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: 13 Aug 2003 22:09:43 +1000
- Subject: Re: Request for a C++ warning for undefined behaviour
- References: <Pine.LNX.firstname.lastname@example.org>
- Reply-to: skaller at ozemail dot com dot au
On Wed, 2003-08-13 at 21:01, Michael Matz wrote:
> On 13 Aug 2003, skaller wrote:
> > If you write that kind of code you deserve everything you get.
> Well, that's the case for all errors one made.
No, I don't agree. It is certainly possible to be coding
in a good style and make an honest mistake.
The code exhibited appears quite perverted to me ..
well, I'm assuming you weren't trying to call a global
function f, and picked up the member f by accident
(that would be an more honest mistake).
> > It would be possible to check if, in a ctor-initialiser, a direct call
> > is made to a virtual function of the current class.
> It's not just virtual functions. You can't call _any_ members before the
> mem-initializers for base classes have complete.
> > Unfortunately, it is possible to circumvent such a check in
> > any number of devious ways, for example by simply wrapping
> > the call in a non-virtual member.
> See above. That's not enough. One would have to go for instance through
> a normal file-static function.
No, you can use a pointer, even this. Then the call is dispatched.
Due to the possibility of aliasing pointers, it again becomes hard to
However, you are right some cases can be detected easily early
in compilation (after overload resolution for functions, and even
earlier for variables).
> > Since you shouldn't be writing code anything remotely like this in the
> > first place, it hardly seems like it would be worthwhile to provide a
> > special case check here.
> That's not a logical conclusion.
The conclusion follows from the assumption that
detecting possible mistakes in code that is using
a faulty design is worthwhile. Better to fix the design.
> Besides, usefullness lies in the eye of
> the beholder. Indeed from your above remarks I would conclude that this
> warning would also be useful to you, because you already made an error in
> your assumptions, namely that you can call non-virtual members.
Nope, I'd never use a ctor-initialiser to initialise a variable
or base other than with a parameter to the constructor, or, at worst,
a component of a structure.
If I have to do any calculations, they go in the body,
and I have to ask myself how I ended up with that,
because it's symptomatic of a design fault.
If I have to calculate something to initialise a base
(which cannot be assigned in a ctor body) I *definitely*
have a design fault.