From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6971 invoked by alias); 18 Nov 2002 02:26:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 6928 invoked by uid 71); 18 Nov 2002 02:26:04 -0000 Date: Fri, 22 Nov 2002 13:48:00 -0000 Message-ID: <20021118022604.6927.qmail@sources.redhat.com> To: paolo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Martin Sebor Subject: Re: libstdc++/5133: Problems with toupper Reply-To: Martin Sebor X-SW-Source: 2002-11/txt/msg00858.txt.bz2 List-Id: The following reply was made to PR libstdc++/5133; it has been noted by GNATS. From: Martin Sebor To: Pete Ratzlaff 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 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 which is probably indirectly #included by . Regards Martin