Re: libstdc++/5133: Problems with toupper

Re: libstdc++/5133: Problems with toupper

[Phil Edwards]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Phil Edwards <phil@jaj.com>
To: Pete Ratzlaff <rpete@legs.harvard.edu>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, paolo@gcc.gnu.org,
   schmid@snake.iap.physik.tu-darmstadt.de
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sat, 16 Nov 2002 03:21:45 -0500

 On Sat, Nov 16, 2002 at 12:19:40AM -0500, Pete Ratzlaff wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133
 > 
 > Apologies, forgot to put the audit trail in my message.
 
 No need to, it's appended by the mailing list software.  Thanks for the
 thought, though.
 
 Phil
 
 -- 
 I would therefore like to posit that computing's central challenge, viz. "How
 not to make a mess of it," has /not/ been met.
                                                  - Edsger Dijkstra, 1930-2002

Re: libstdc++/5133: Problems with toupper

[Pete Ratzlaff]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Pete Ratzlaff <rpete@legs.harvard.edu>
To: Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/5133: Problems with toupper 
Date: Mon, 18 Nov 2002 00:50:16 -0500

 > > 
 > > I cannot see anything that keeps one from using the toupper/tolower
 > > from <cctype> with transform, and the fact that gcc won't allow it
 > > should be considered a bug.
 > 
 > Yes, but only if it's the only available function. The other comes
 > from <locale> which is probably indirectly #included by <iostream>.
 > 
 
 I had heard this argument before, for the case when both overloads from
 <locale> and <cctype> are in scope, but didn't know whether to believe
 it since no citations were ever shown. After digging around a bit (the
 template section of the standard is *dense*), I finally came across
 this:
 
 14.8.2.4
 
   16- A template-argument can be deduced from a pointer to function or
       pointer to member function argument if the set of overloaded
       functions does not contain function templates and at most one of a
       set of overloaded functions provides a unique match.
 
 So unless I'm misinterpretting, then your new explanation makes sense
 and gcc is conforming to the standard in this respect.
 
 Cheers,
 -Pete

Re: libstdc++/5133: Problems with toupper

[Martin Sebor]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: Pete Ratzlaff <rpete@legs.harvard.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sun, 17 Nov 2002 19:27:09 -0700

 Pete Ratzlaff wrote:
 ...
 > 
 > All I can guess is that Martin was thinking of the std::ptr_fun and
 > std::pointer_to_unary_function templates, whose argument (and ctor)
 > are explicitly pointers to function (with C++ linkage).
 
 I think what I was trying to say (but didn't do a very good job)
 was that in the call to std::transform (..., toupper), the compiler
 can't choose between the two overloads of the function: extern "C"
 toupper (int) and the two-argument template toupper, and it cannot
 even deduce the type of the template toupper. If only the extern "C"
 function were found, the call would be unambiguous. The linkage was
 a red herring (gcc doesn't distinguish between one and the other
 but it doesn't have anything to do with the the error). Sorry if
 I confused things.
 
 > 
 > I cannot see anything that keeps one from using the toupper/tolower
 > from <cctype> with transform, and the fact that gcc won't allow it
 > should be considered a bug.
 
 Yes, but only if it's the only available function. The other comes
 from <locale> which is probably indirectly #included by <iostream>.
 
 Regards
 Martin
 

Re: libstdc++/5133: Problems with toupper

[Pete Ratzlaff]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Pete Ratzlaff <rpete@legs.harvard.edu>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc: paolo@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sat, 16 Nov 2002 00:19:40 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133
 
 Apologies, forgot to put the audit trail in my message.
 
 -Pete

Re: libstdc++/5133: Problems with toupper

[Pete Ratzlaff]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Pete Ratzlaff <rpete@legs.harvard.edu>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc: paolo@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sat, 16 Nov 2002 00:17:10 -0500

 I realize this PR is closed, but don't agree with the conclusion that
 mixing linkages in this case is ill-formed.  There's is nothing to
 preclude the template argument from being a function with C
 linkage. Here is what the standard has to say:
 
 template<class InputIterator, class OutputIterator,
          class UnaryOperation>
   OutputIterator
     transform(InputIterator first, InputIterator last,
               OutputIterator result, UnaryOperation op);
 
   1- Effects: Assigns through every iterator i in the range [result,
      result + (last1 - first1)) a new corresponding value equal to
      op(*(first1 + (i - result))
 
 In other words, anything that can have an () appended and follows the
 rules for template parameters is fair game for the 3rd template
 argument in this case.
 
 All I can guess is that Martin was thinking of the std::ptr_fun and
 std::pointer_to_unary_function templates, whose argument (and ctor)
 are explicitly pointers to function (with C++ linkage).
 
 I cannot see anything that keeps one from using the toupper/tolower
 from <cctype> with transform, and the fact that gcc won't allow it
 should be considered a bug.
 
 Although it certainly doesn't prove my point, I would just note that
 Comeau's compiler seems to concur.
 
 Cheers,
 -Pete

Re: libstdc++/5133: Problems with toupper

[paolo]

Synopsis: Problems with toupper

State-Changed-From-To: feedback->closed
State-Changed-By: paolo
State-Changed-When: Thu Oct 31 16:08:39 2002
State-Changed-Why:
    We can close this one too.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133

Re: libstdc++/5133: Problems with toupper

[Christopher Currie]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: "Christopher Currie" <christopher@currie.com>
To: <gcc-gnats@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<paolo@gcc.gnu.org>,
	<schmid@snake.iap.physik.tu-darmstadt.de>
Cc: <philip@codematters.co.uk>,
	<libstdc++@gcc.gnu.org>
Subject: Re: libstdc++/5133: Problems with toupper
Date: Fri, 28 Jun 2002 00:42:34 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 r=5133
 
 Sorry to dig up this old PR, but it seems to still be in feedback state, and
 I've been working with the problem recently and I wanted to weigh in.
 
 Philip Martin wrote:
 > using the function template is
 > tricky because the second parameter is a reference. One would like to
 > try
 >
 >   // this won't work
 >   std::locale loc;
 >   std::transform(s.begin(),s.end().s.begin(),
 >                  std::bind2nd(std::ptr_fun(std::tolower<char>),loc));
 >
 > but this will suffer from the reference to a reference problem.
 
 Without going into too much detail, the problem is detected in binder2nd's
 constructor, but can be traced to the definition of the binary_function
 template. I was able to get the above code working by adding a
 specialization of the template, used when the second argument is a
 reference:
 
 #include <functional>
 #include <algorithm>
 #include <string>
 #include <locale>
 
 namespace std
 {
 // specialization for the second argument being a reference
 template <class _Arg1, class _Arg2, class _Result>
 struct binary_function<_Arg1, _Arg2&, _Result> {
   typedef _Arg1 first_argument_type;
   typedef _Arg2 second_argument_type;
   typedef _Result result_type;
 };
 }
 
 int main()
 {
   using namespace std;
   string s ("Someone Chanted Evening");
   locale loc;
 
   transform(s.begin(), s.end(), s.begin(),
       bind2nd(ptr_fun(&tolower<char>), loc));
 
   return 0;
 }
 
 Naturally, a second specialization would be necessary for the first
 argument, so that bind1st will also behave as expected.
 
 The remaining questions: Does this specialization violate the Standard,
 and/or will it break existing code?
 
 Comments and criticisms welcome.
 
 Christopher Currie
 

Re: libstdc++/5133: Problems with toupper

[Philip Martin]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Philip Martin <philip@codematters.co.uk>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, paolo@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de, sebor@roguewave.com
Cc:  
Subject: Re: libstdc++/5133: Problems with toupper
Date: 17 Dec 2001 16:01:28 +0000

 > #include <string>
 > #include <iostream> // does work, when this line is removed
 > #include <algorithm>
 > #include <cctype>
 > 
 > int main()
 > {
 >     std::string s("Hallo");
 >     std::transform (s.begin(), s.end(), s.begin(), std::tolower);
 >     std::transform (s.begin(), s.end(), s.begin(), ::tolower);
 > }
  
 Using gcc the include of <iostream> brings in a declaration of the
 function template
 
   namespace std { template<class T> T tolower(T, const locale&); }
 
 and the include of <cctype> brings in the functions
 
   extern "C" int tolower(int);
   namespace std { using ::tolower; }
 
 [The global scope tolower function is a separate problem, but doesn't
 affect this PR.]
 
 Now, I believe you are trying to call the tolower function, rather
 than the tolower function template. I don't understand template
 argument deduction well enough to be able to say whether the compiler
 should work out that this is what you want, but you can tell it
 explicitly
 
   typedef std::string::iterator I;
   std::transform<I,I,int(*)(int)>transform(s.begin(),s.end(),s.begin(),std::tolower);
 
 This compiles with gcc 3.0.3 and gcc 3.1. However it doesn't address
 the "C"/"C++" linkage point mentioned by Martin. One can avoid that by
 using the function template, however using the function template is
 tricky because the second parameter is a reference. One would like to
 try
 
   // this won't work
   std::locale loc;
   std::transform(s.begin(),s.end().s.begin(),
                  std::bind2nd(std::ptr_fun(std::tolower<char>),loc));
 
 but this will suffer from the reference to a reference problem. If you
 wish to pursue this you should consider using the bind library from
 boost (http://www.boost.org) instead of std::bind2nd
 
 -- 
 Philip

Re: libstdc++/5133: Problems with toupper

[Martin Sebor]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5133: Problems with toupper
Date: Sun, 16 Dec 2001 18:54:22 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133
 
 None of the programs in this PR is well-formed for at least two reasons:
 
     1. The first two refer to ::tolower or tolower without either first
        #including <ctype.h>, or #including <cctype> *and* bringing              
 std::tolower into the global namespace via a using declaration
        or directive.
 
     2. The four-argument overload of std::transform() is a template
        that expects a unary function [object] as its last argument,
        i.e., a class type that defines operator() or a one argument
        function with extern "C++" linkage. None of the two overloads
        of std::tolower is likely to be such a function (the unary
        version that's intended to be used is likely to have an extern
        "C" linkage since it's a C library function). In fact, they are
        known to be extern "C" in glibc on Linux, the reported platform.
 
 Paolo's suggested change suffers from a variant of 1, except that it
 doesn't qualify the name at all. It has the same problem as 2. IMO,
 there are two reasons why this example compiles with gcc: one of the
 headers inadvertently introduces the unary function tolower into the
 global namespace, and the compiler fails to diagnose the incompatibility
 of an extern "C" function with a pointer to an extern "C++" function.
 
 The short story is that you cannot portably pass a function declared
 in one of the C++ C library headers (such as <cctype> or the deprecated
 <ctype.h>) as a template argument to a function template, since the
 linkage of the latter requires that that the argument have C++ linkage
 which is not guaranteed by the C++ Standard. For this reason, the
 example is Jossutis' book is unportable and ill-formed on all platforms
 I'm familiar with.
 
 Regards
 Martin

Re: libstdc++/5133: Problems with toupper

[Peter Schmid]

The following reply was made to PR libstdc++/5133; it has been noted by GNATS.

From: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
To: paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        nobody@gcc.gnu.org, paolo@gcc.gnu.org,
        schmid@snake.iap.physik.tu-darmstadt.de, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5133: Problems with toupper
Date: Mon, 17 Dec 2001 00:39:53 +0100 (CET)

 On 16 Dec 2001 paolo@gcc.gnu.org wrote:
 
 > Synopsis: Problems with toupper
 > 
 > Responsible-Changed-From-To: unassigned->paolo
 > Responsible-Changed-By: paolo
 > Responsible-Changed-When: Sun Dec 16 13:53:55 2001
 > Responsible-Changed-Why:
 >     Taking care of this.
 > State-Changed-From-To: open->feedback
 > State-Changed-By: paolo
 > State-Changed-When: Sun Dec 16 13:53:55 2001
 > State-Changed-Why:
 >     Hi Peter,
 >     
 >     in Josuttis, pp. 499 and 718 I find an explanation of what
 >     is happening with your testcase. In a nutshell, tolower and
 >     toupper are old C functions (you may use them through
 >     cctype) whereas std::toupper(c, loc) (and the corresponding
 >     tolower) are global functions of the C++ locales.
 >     Therefore, your testcase should be changed to:
 >     
 >     #include <string>
 >     #include <iostream> 
 >     #include <algorithm>
 >     #include <cctype>
 >     
 >     int main()
 >     {
 >         std::string s("Hallo");
 >         //std::transform (s.begin(), s.end(), s.begin(), std::tolower);
 >         //std::transform (s.begin(), s.end(), s.begin(), ::tolower);
 >         std::transform (s.begin(), s.end(), s.begin(), tolower);
 >         std::cout << "lowered: " << s << std::endl;
 >     }
 >     
 >     which indeed compiles and runs fine.
 >     
 >     Ok?
 >     
 >     Cheers,
 >     Paolo.
 >     
 >      
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133
 > 
 
 It is IMHO not ok. If you consider the following source tl.C, a stripped
 down version from string/iter1.C from Josuttis, cf. pages number
 497--499. Also cf. page number 720. 
 
 I believe that this source code is legal and according to Josuttis the
 <c*> headers inject the corresponding <*.h> functions into the std
 namespace. Therefore, I have no idea why this code, the call to std::tolower
 is rejected. Additionally, why does the code compile if the iostream
 header is removed?
 
 Peter Schmid 
 
 
 tl.C
 #include <string>
 #include <iostream> // does work, when this line is removed
 #include <algorithm>
 #include <cctype>
 
 using namespace std;
 
 int main()
 {
     string s("Hallo");
     transform (s.begin(), s.end(), s.begin(), tolower);
     transform (s.begin(), s.end(), s.begin(), ::tolower);
 }
 
 g++ -o tl tl.C -W -Wall
 tl.C: In function `int main()':
 tl.C:11: no matching function for call to `transform(
    std::__normal_iterator<char*, std::basic_string<char, 
    std::char_traits<char>, std::allocator<char> > >, 
    std::__normal_iterator<char*, std::basic_string<char, 
    std::char_traits<char>, std::allocator<char> > >, 
    std::__normal_iterator<char*, std::basic_string<char, 
    std::char_traits<char>, std::allocator<char> > >, <unknown type>)'
 

Re: libstdc++/5133: Problems with toupper

[paolo]

Synopsis: Problems with toupper

Responsible-Changed-From-To: unassigned->paolo
Responsible-Changed-By: paolo
Responsible-Changed-When: Sun Dec 16 13:53:55 2001
Responsible-Changed-Why:
    Taking care of this.
State-Changed-From-To: open->feedback
State-Changed-By: paolo
State-Changed-When: Sun Dec 16 13:53:55 2001
State-Changed-Why:
    Hi Peter,
    
    in Josuttis, pp. 499 and 718 I find an explanation of what
    is happening with your testcase. In a nutshell, tolower and
    toupper are old C functions (you may use them through
    cctype) whereas std::toupper(c, loc) (and the corresponding
    tolower) are global functions of the C++ locales.
    Therefore, your testcase should be changed to:
    
    #include <string>
    #include <iostream> 
    #include <algorithm>
    #include <cctype>
    
    int main()
    {
        std::string s("Hallo");
        //std::transform (s.begin(), s.end(), s.begin(), std::tolower);
        //std::transform (s.begin(), s.end(), s.begin(), ::tolower);
        std::transform (s.begin(), s.end(), s.begin(), tolower);
        std::cout << "lowered: " << s << std::endl;
    }
    
    which indeed compiles and runs fine.
    
    Ok?
    
    Cheers,
    Paolo.
    
     

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5133

libstdc++/5133: Problems with toupper

[Peter Schmid]

>Number:         5133
>Category:       libstdc++
>Synopsis:       Problems with toupper
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 16 13:16:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Peter Schmid
>Release:        3.1 20011216 (experimental)
>Organization:
TU Darmstadt
>Environment:
System: Linux kiste 2.4.14 #5 Thu Nov 8 13:35:20 CET 2001 i686 unknown
Architecture: i686
SuSE 7.3
GNU ld version 2.11.90.0.29
Glibc 2.2.4
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-clocale=gnu --enable-languages=c,c++,f77,objc
>Description:
The legal source file tl.C is rejected by gcc 3.0.3 and by gcc 3.1. gcc 2.95.3
accepts this code, though. When I compile and link versus STLport 4.5,
both gcc 3.0.3 and gcc 3.1 have no problem compiling the source
code. If the header file <iostream> is not included, all compilers
compile the source code into a working executable. Therefore, I guess
there is a coding error in libstdc++. 

>How-To-Repeat:
Source code tl.C
#include <string>
#include <iostream> // does work, when this line is removed
#include <algorithm>
#include <cctype>

int main()
{
    std::string s("Hallo");
    std::transform (s.begin(), s.end(), s.begin(), std::tolower);
    std::transform (s.begin(), s.end(), s.begin(), ::tolower);
}

g++ -v -W -Wall tl.C 
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-clocale=gnu --enable-languages=c,c++,f77,objc
Thread model: posix
gcc version 3.1 20011216 (experimental)
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -W -Wall -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ tl.C -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase tl.C -W -Wall -version -o /tmp/cci4lLgB.s
GNU CPP version 3.1 20011216 (experimental) (cpplib) (i386 Linux/ELF)
GNU C++ version 3.1 20011216 (experimental) (i686-pc-linux-gnu)
	compiled by GNU C version 3.1 20011216 (experimental).
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++-v3
 /usr/local/include/g++-v3/i686-pc-linux-gnu
 /usr/local/include/g++-v3/backward
 /usr/local/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/include
 /usr/include
End of search list.
tl.C: In function `int main()':
tl.C:9: no matching function for call to `transform(
   std::__normal_iterator<char*, std::basic_string<char, 
   std::char_traits<char>, std::allocator<char> > >, 
   std::__normal_iterator<char*, std::basic_string<char, 
   std::char_traits<char>, std::allocator<char> > >, 
   std::__normal_iterator<char*, std::basic_string<char, 
   std::char_traits<char>, std::allocator<char> > >, <unknown type>)'

>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: