Date: Tue, 23 Jul 2002 07:53:30 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com Subject: Re: Bug in DJGPP 2.03 (with GCC 3.1) In-Reply-To: <10207222257.AA27589@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 22 Jul 2002 sandmann AT clio DOT rice DOT edu wrote: > > tanhf and the other functions listed became part of the C standard in C99. But > > DJGPP doesn't support C99 yet. These functions are in the non-standard section > > of and are therefore unavailable, when you use the -ansi option. > > (Look for the #ifndef __STRICT_ANSI__, #ifndef _POSIX_SOURCE lines.) > > > > I suspect that gcc 2.95.3 didn't have std::tanhf and the others, so this > > problem did not arise. > > So this means that 2.03 is incompatible with gcc 3.x with -ansi ? Yes. > Should we consider a header change for 2.03 refresh to fix? Or is it > more complicated? There are other headers, besides math.h, which have the same problem: functions standardized by C99 have their prototypes masked under -ansi. If we decide to fix math.h, we should fix the other headers as well. I don't know what should the compiler do if invoked with -c89 (sp?) switch, though? Should it omit the prototypes of functions that were non-standard in C89? Does that interact in some way with -ansi? If we need to do something else about these cases, the fix might be more complicated than just moving some prototypes.