Re: stdio.h patches for g++ -std=c++11

[Eric Blake <eblake at redhat dot com>]

On 05/10/2014 06:49 AM, zosrothko wrote:
> Hi Corinna

I'm coming into this thread late, so I may be missing some context.


> int    _EXFUN(vfscanf, (FILE *__restrict, const char *__restrict, __VALIST)
>                _ATTRIBUTE ((__format__ (__scanf__, 2, 0))));
> 
> 
> Please notice that vfscanf is not part of the ISO/IEC 14882-2011 norm
> but I think it is a mistake.

Mistake or not, you need to first pursue getting it fixed in the C++
standard, and in the meantime comply with the standard as written (when
in strict mode, don't expose it; but it is fine to expose as an extension).


>>>>
>>>> The 'i' functions are a newlib extension for embedded targets.
>>>>
>>>> They are not part of any standard, so they are certainly neither part
>>>> of "__cplusplus >= 201103L", nor part of "__STDC_VERSION__ >= 199901L".


"__cplusplus >= 201103L" merely says whether we are using a particular
version of C++ or newer, and not whether we are being strictly compliant
to that exact version of C++.  Exposing extensions is fine in all cases
where the user has not requested strict compliance to an exact standard,
although I'm a bit fuzzy on the constructs used in newlib for
determining whether strict compliance is in effect.  For that matter, I
think several people have complained that newlib is currently very poor
at not polluting the namespace when requesting strict compliance, which
is a bigger bug to be tackled incrementally.

>>>>
>>>> So, either we remove these functions from both standards, or we include
>>>> them in both standards.

That reads awkwardly.  It is more a question of whether we are allowed
to pollute the namespace with an 'i' function or whether strict
compliance to a standard demands that we suppress it.

Ideally, I think that newlib should expose as much as possible by
default, and then that you tune in higher levels of standards compliance
that hides declarations that are no longer appropriate for that
increased level of strictness.

>>>>
>>>> But if we remove them from both standards when will they be defined at
>>>> all?  This should be cleared up before making this change.

It is not whether we "remove them from both standards", but rather
whether we hide the namespace pollution when being strictly compliant to
a particular standard.  But what are the tests we are using to determine
when strict compliance is in effect?

The current code tries to expose some sets of functions based on which
standard appears to be the minimum in use, although I think the much
easier way to reason is to default to full exposure, and merely hide
declarations when a particular standard says it should not pollute the
namespace.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature