This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ Standard Question

On 1/23/2015 9:55 AM, Jonathan Wakely wrote:
> On 22/01/15 16:07 -0600, Joel Sherrill wrote:
>> On 1/22/2015 3:44 PM, Marc Glisse wrote:
>>> On Thu, 22 Jan 2015, Joel Sherrill wrote:
>>>> I think this is a glibc issue but since this method is defined in the C++
>>>> standards, I thought there were plenty of language lawyers here. :)
>>> s/glibc/libstdc++/ and they have their own ML.
>>  Thank you.
>>>> <strstream>
>>> That's deprecated, isn't it?
>> Yes. There is also a warning about that coming from the test code.
>> I don't know how long it has been deprecated since even with
>> -std=c++03, the warning is present.
> Those types were deprecated even in the first C++ standard in 1998.
> They were born deprecated, and have remained so ever since.
I don't mind the deprecated warning but at least I know now how long they
have been that way. :)
>>>>   class strstreambuf : public basic_streambuf<char, char_traits<char> >
>>>>   ISSUE ====> int pcount() const;   <===== ISSUE
>>>> My reading of the C++03 and draft C++14 says that the int pcount() method
>>>> in this class is not const. glibc has it const in the glibc shipped with
>>>> Fedora 20
>>>> and CentOS 6.
>>>> This is a simple test case:
>>>>    #include <strstream>
>>>>    int main() {
>>>>        int (std::strstreambuf::*dummy)() = &std::strstreambuf::pcount;
>>>> /*-- pcount is conformant --*/
>>>>        return 0;
>>>>    }
>>>> What's the consensus?
>>> The exact signature of member functions is not mandated by the standard,
>>> implementations are allowed to make the function const if that works (or
>>> provide both a const and a non-const version). Your code is not guaranteed
>>> to work. Lambdas usually provide a fine workaround.
>> This code is actually from the Open Group FACE Conformance Test Suite.
>> It uses code like this to check the presence of methods from the C Standard
>> Library, POSIX APIs, and the C++ Standard Library. It would be really
>> helpful
>> if you could cite the place in the C++ standard so I can provide that as
>> feedback
>> to the authors of the test suite.
> [member.functions] gives implementors certain freedoms to
> provide slightly different signatures to those described in the
> standard, including this:
> -2- It is unspecified whether any member functions in the C++ standard
>     library are defined as inline (7.1.2). An implementation may
>     declare additional non-virtual member function signatures within a
>     class:
>     â by adding arguments with default values to a member function
>     signature;(187)
>     â ...
>     187) Hence, the address of a member function of a class in the C++
>     standard library has an unspecified type.
> The footnote makes it clear that we could declare strstreambuf::pcount
> as a function with one or more parameters, as long as we give them
> default values, meaning that the type of &std::strstreambuf::pcount is
> not guaranteed to be int (strstreambuf::*)() in a conforming
> implementation, so the conformance test could fail on an
> implementation that conforms 100% to the standard.
> I'm not sure if that gives us the liberty to add 'const' where the
> standard doesn't have it, so this might be a real non-conformance
> issue, but even if we fixed it their test is not guaranteed to work
> for other reasons.
Thank you for the explanation.

Sounds like every place this technique flags a method, it cannot be an
automatic fail but will need manual examination to at least check for
defaulted arguments.

I am curious what the ruling is on the const. Since the answer will
impact FACE's guidance for its test suite.

Is there a better way to automate a signature compliance? To tweak
what they have done?

>> On a positive note, the test suite isn't flagging much using this
>> technique. This
>> may be the only method. But I would like to provide the correct feedback to
>> them so no one else deals with this.
> IMHO the correct feedback for these deprecated types might be "Hmm,
> you're right. Oh well, nevermind, we're not going to bother fixing it
> now."
> Any real program using the pcount() member will work correctly with
> our implementation. In practice only conformance tests are likely to
> notice the difference.

Joel Sherrill, Ph.D.             Director of Research & Development        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]