Fix compilation errors with libstdc++v3 for AVR target and allow --enable-libstdcxx

[Jonathan Wakely]

On 14/12/16 18:38 -0300, Felipe Magno de Almeida wrote:
>Hello Jonathan,
>
>Sorry for the delay, I was in mid-vacation.
>
>Comments are inline.
>
>On Tue, Dec 6, 2016 at 3:45 PM, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 16/09/16 02:53 -0300, Felipe Magno de Almeida wrote:
>>>
>
>[snip]
>
>>> I've tried both approaches. Templates were causing problems of not
>>> defined instantations because they were being used as ints too
>>> in other _M_extract functions through a tmp integer. And typedef's
>>> caused the same problem of having to use a tmp value of the right
>>> type but for example _M_extract_wday_or_month could not have the
>>> same type (in AVR they do) and I'd have to use a temporary anyway
>>> then.
>>>
>>> This was the least intrusive way.
>>
>>
>> Did you consider something like this?
>
>I have, but I did not like how it could run code that is not very explicit
>in case of exceptions, possibly assigning from a non-initialized variable,

OK, but that assignment from a possibly-uninitialized variable was
also present in your original patch.

>causing, theoretically UB. Besides, __mem was already used for
>tm_mom, so it seemed best to just mimic for the rest.

Yes, but now we have that overhead of extra reads and writes for every
function, not just that one.

>I have another patch attached which fixes the problem you mentioned
>and the same problem with the tm_wday in a different switch-case.
>I've removed all initializations of __mem, the same way that tm_mon
>already did not initialize it, because the value is not actually used at
>all in extract_num and variants.

Doesn't this now mean that if an error happens in the _M_extract_xxx
function we set tm.tm_xxx to garbage?

The existing tm.tm_mon case handles that correctly, by checking for an
error first.

>I have ran the test and nothing on locale failed, I've ran again with the fixes,
>and there are also no errors on locale. Testing with x86_64.

Good, thanks for testing it.