public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/5133: Problems with toupper
@ 2001-12-16 17:46 Martin Sebor
0 siblings, 0 replies; 12+ messages in thread
From: Martin Sebor @ 2001-12-16 17:46 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-11-22 14:46 Pete Ratzlaff
0 siblings, 0 replies; 12+ messages in thread
From: Pete Ratzlaff @ 2002-11-22 14:46 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-11-22 13:48 Martin Sebor
0 siblings, 0 replies; 12+ messages in thread
From: Martin Sebor @ 2002-11-22 13:48 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-11-22 5:43 Phil Edwards
0 siblings, 0 replies; 12+ messages in thread
From: Phil Edwards @ 2002-11-22 5:43 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-11-22 5:41 Pete Ratzlaff
0 siblings, 0 replies; 12+ messages in thread
From: Pete Ratzlaff @ 2002-11-22 5:41 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-11-22 5:11 Pete Ratzlaff
0 siblings, 0 replies; 12+ messages in thread
From: Pete Ratzlaff @ 2002-11-22 5:11 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-10-31 16:08 paolo
0 siblings, 0 replies; 12+ messages in thread
From: paolo @ 2002-10-31 16:08 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, paolo, schmid
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2002-06-27 23:14 Christopher Currie
0 siblings, 0 replies; 12+ messages in thread
From: Christopher Currie @ 2002-06-27 23:14 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2001-12-17 8:06 Philip Martin
0 siblings, 0 replies; 12+ messages in thread
From: Philip Martin @ 2001-12-17 8:06 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2001-12-16 15:46 Peter Schmid
0 siblings, 0 replies; 12+ messages in thread
From: Peter Schmid @ 2001-12-16 15:46 UTC (permalink / raw)
To: paolo; +Cc: gcc-prs
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>)'
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: libstdc++/5133: Problems with toupper
@ 2001-12-16 13:53 paolo
0 siblings, 0 replies; 12+ messages in thread
From: paolo @ 2001-12-16 13:53 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, paolo, schmid
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* libstdc++/5133: Problems with toupper
@ 2001-12-16 13:16 Peter Schmid
0 siblings, 0 replies; 12+ messages in thread
From: Peter Schmid @ 2001-12-16 13:16 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-11-18 5:56 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-16 17:46 libstdc++/5133: Problems with toupper Martin Sebor
-- strict thread matches above, loose matches on Subject: below --
2002-11-22 14:46 Pete Ratzlaff
2002-11-22 13:48 Martin Sebor
2002-11-22 5:43 Phil Edwards
2002-11-22 5:41 Pete Ratzlaff
2002-11-22 5:11 Pete Ratzlaff
2002-10-31 16:08 paolo
2002-06-27 23:14 Christopher Currie
2001-12-17 8:06 Philip Martin
2001-12-16 15:46 Peter Schmid
2001-12-16 13:53 paolo
2001-12-16 13:16 Peter Schmid
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).