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.
> 17.6.5.5 [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
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
