Re: [PATCH 03/36] C++ keyword cleanliness, mostly auto-generated

[Pedro Alves <palves@redhat.com>]

On 02/12/2015 12:19 PM, Joel Brobecker wrote:
>> On 02/11/2015 10:27 AM, Pedro Alves wrote:
>>
>>> Below's the patch that I plan on folding in.  Builds in C and C++ modes.
>>> Regtesting in progress.
>>
>> Regtesting successful.  Here's the current version of the patch.
> 
> Thanks a lot, Pedro, this is great.

Great, thanks.

> 
> I haven't had a chance to review all the patches, and I will admit
> that I winced a little when seeing some of them (but accepted them),

Not sure whether I want to ask which.  :-)

> but overall, I'm very impressed to see progress in this area.

Thanks.

> 
> Two comments:
> 
>   1. I personally am not ready for a full switch to C++ ;-)
>      I know it's not what this patch does, but just sayin' :-).
>      Will work on it, though, but if you had some ideas of how soon
>      you'd like to do the switch, that might help me plan better.

I don't have target dates in mind.  :-)  There's still work to do.

Before we start using C++ features, and thus stop supporting building
GDB as a C program, I think we should have a period where we'll
switch to C++ by default, while still leaving the C mode option
available as fallback.  Only when we're sure all supported
hosts / configurations build and work correctly, can we drop the
C mode and start using C++ features.

For fully converting to be a valid C++ program, we need to get rid
of the -fpermissive shortcut.  E.g., 'char *s = xmalloc (size);' needs
a cast in C++, but -fpermissive downgrades that to a warning.
There's another similarly sized series on my github to address that,
but it needs cleaning up and possibly redoing parts.  I can't tell
when I'll be able to get to it.  It may take several weeks to land
all that in mainline, unless I manage to recruit help (hint!, hint!).

There's also the "we shouldn't throw from signal handlers" issue I
mentioned in the reply to Yao, which has nobody working on
yet, afaik.

>   2. This is a fairly massive patch series, and in the interest
>      of not making it inhuman for you to maintain it, I would be
>      perfectly fine with a fairly quick process towards getting
>      those patches pushed. Apart from the last few ones dealing
>      with TRY_CATCH, it's fairly simple patches.

Thanks, that'd be great.

Thanks,
Pedro Alves