X-Spam-Check-By: sourceware.org Message-ID: <44033332.7020801@redhat.com> Date: Mon, 27 Feb 2006 12:13:22 -0500 From: Jeff Johnston User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) MIME-Version: 1.0 To: Gabriel Dos Reis Cc: Dave Korn , cygwin AT cygwin DOT com, libstdc++@gcc.gnu.org, newlib AT sources DOT redhat DOT com Subject: Re: gcc-3.4.4-1: c++: cmath: calling std::isnan results in endless loop References: <01d101c63bb9$ef9ead20$a501a8c0 AT CAM DOT ARTIMI DOT COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Gabriel Dos Reis wrote: > "Dave Korn" writes: > > [...] > > | It looks to me like the cygwin/newlib combination is not being compliant if > | it implements isnan as a function rather than a macro. I couldn't see > | anything in the standard that says it can be a function, and every reference > | to it describes it as a macro, not a function. It may be the case that > | libstdc++ is within its rights to assume that isnan is a macro after all. > > yes, isnan and friends are supposed to be macros only, not functions. > I'll start working on a newlib patch for this. > | OTOH it may be that libstdc++ was only supposed to be shadowing those ctype > | macros that are guaranteed to have underlying function implementations; I > | don't know what the shadowing is for, so I can't comment. > > libstdc++ is supposed to shadow ctype macros -- and it also expect > them to have a function implementation. > > -- Gaby -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/