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

[Richard Smith]

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. 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.

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).