Re: [RFA v2 10/17] C++ify mi_parse

[Pedro Alves <palves@redhat.com>]

On 04/12/2017 08:25 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> FYI, I just now tried the hack below against master, and
> Pedro> that caught a few other cases that shouldn't have been
> Pedro> using memset for initialization.
> [...]
> Pedro> I wonder how bad would it be to put this hack in master.  Guess
> Pedro> we could always add it behind an #if 0 at least, to make it easy
> Pedro> to enable for quick checking?
> 
> I think it would be helpful if the compiler could warn about missing
> member initializations in a constructor.

Yeah, that would be nice.  In principle, -Wuninitialized would catch
those too, and be quiet if you have some field that you do want to
be left uninitialized in the ctor (e.g., some big array lazily
filled in).  (And for OOL ctors, there's -flto.)
There are unfortunately a number of bugs with it, though.
The last I ran into was:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658

> That would make something like
> the mi_parse change more robust, which I think is the reason for the
> memsets in the first place.

Yeah.  The memsets become invalid as soon as your ctor
does something non-trivial though, we really need to zap them
sooner than later.  My current thinking is that in-class initialization
helps by making it easier to check whether all fields have default
initialization.

I've posted a series fixing the issues the hack caught, and some more,
along with a better version of the hack, here:

 https://sourceware.org/ml/gdb-patches/2017-04/msg00378.html

Thanks,
Pedro Alves