[cfe-dev] [libc++] gets removed from C11

[Richard Smith]

On Mon, Jul 1, 2013 at 5:12 PM, Howard Hinnant <hhinnant at apple.com> wrote:
> On Jul 1, 2013, at 7:55 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
>> On Mon, Jul 1, 2013 at 4:10 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>>> On Jul 1, 2013, at 1:56 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>
>>>> On Sun, Jun 30, 2013 at 2:07 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>>>>> Please review the enclosed patch which guards against the removal of gets from <stdio.h> in C11 and addresses:
>>>>>
>>>>> http://llvm.org/bugs/show_bug.cgi?id=16369
>>>>>
>>>>> The current patch is known to be correct only on __APPLE__.  I need help from those testing libc++ on other platforms.  Specifically, <__config> now has:
>>>>>
>>>>> +#ifdef __APPLE__
>>>>> +#define _LIBCPP_HAS_GETS
>>>>> +#endif
>>>>>
>>>>> which causes <cstdio> to expose gets:
>>>>>
>>>>> +#ifdef _LIBCPP_HAS_GETS
>>>>> using ::gets;
>>>>> +#endif
>>>>>
>>>>> I need to know what other platforms (and possibly under what circumstances) should define _LIBCPP_HAS_GETS.  Patches to <__config> in reply to this request for a review are welcome.  It would be nice to not break others when checking in the fix for http://llvm.org/bugs/show_bug.cgi?id=16369.
>>>>
>>>> I wonder if this approach is backwards. A <stdio.h> should provide
>>>> gets unless it's in C11 mode. No C++ mode is C11, so if the
>>>> implementation fails to provide gets in C++, then it's broken. Perhaps
>>>> we should blacklist the broken implementations instead of whitelist
>>>> the known-working ones?
>>>
>>> Consider this:  Ultimately, the fewer customization flags the better.  And eventually gets() will disappear everywhere. When that happens, use of _LIBCPP_HAS_GETS will disappear too, and so it can be removed since no platform will be defining it.
>>>
>>> As each platform drops gets(), and thus stops defining _LIBCPP_HAS_GETS, we will discover at that time if any clients on that platform have been testing _LIBCPP_HAS_GETS and actually need it to be defined.  Each platform can deal with that as part of their plan on removing gets().
>>>
>>> If we reverse the flag, _LIBCPP_DOES_NOT_HAVE_GETS will be used by everyone  when gets() disappears everywhere.  This will make it harder to remove from libc++ because since every platform uses it, every platform's clients could also be testing against _LIBCPP_DOES_NOT_HAVE_GETS.
>>
>> gets should not disappear if <stdio.h> is included in C++98 or C++11
>> mode. If it does, that's a bug; it isn't platforms slowly adopting a
>> feature.
>
> I completely agree.
>
>> glibc had that bug for two months (as far as I can tell, it
>> never made it into a glibc release), and have already fixed it:
>>
>>  http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c6e013c15e0091edc49affd6ce26562845000dcd
>>
>> Punishing all platforms for a glibc bug which is already fixed (and
>> was never in a glibc release) doesn't seem reasonable, not matter how
>> bad we all agree "gets" is.
>
> I should've defined what I meant by "ultimately".  I'm thinking long term ... decades.  In 2033 clang and libc++ might decide they no longer want to support C++11 (for example).  If not 2033, maybe 2050.  At some point in the future, I hope that clang and libc++ will still be going, but they will care less about the standards we are supporting today, which will surely have been superseded by future standards.
>
> I agree that asking other platforms to define _LIBCPP_HAS_GETS is a bit of a pain.  But I wouldn't call it punishment.  And the trend, looking decades into the future, is that the requirement for _LIBCPP_HAS_GETS will decrease, not increase.  If you do think of this as punishment, then if we reverse the flag, the punishment increases over time, not decreases.
>
> Either way, I don't think it is the end of the world.  We have lots of configuration flags and we will never get to a point where we don't need them.  I just like to define them in such a way that the need for the flag decreases as time moves on, as opposed to increases.  This is the same thinking behind _LIBCPP_HAS_NO_NULLPTR, as opposed to _LIBCPP_HAS_NULLPTR.  Eventually no platform will care to define _LIBCPP_HAS_NO_NULLPTR and maybe we can get rid of it.  Probably won't happen until after I retire...
>
>>
>> Maybe declare gets yourself, #if __GLIBC__ == 2 && __GLIBC_MINOR__ ==
>> 15. This approximately matches how libstdc++ works around the glibc
>> bug.
>>
>>
>> Separately, we should push for 'gets' to be removed from C++14
>> (someone needs to file a national body comment for that), and then
>> libc++ should provide its using declaration whenever __cplusplus <=
>> 201103L (with a workaround for the broken glibc version as above). If
>> we don't do this, then we're going to need to work around the glibc
>> bug in C++14 mode too (where, again, it doesn't declare gets).
>
> Agreed.  But I think it is too late, at least for US delegates, unless someone already did it.  The deadline for US comments was yesterday.

UK is still accepting ballot comments; I've added this one to the list.