delorie.com/archives/browse.cgi | search |
From: | <ams AT ludd DOT luth DOT se> |
Message-Id: | <200308271827.h7RIR9I0004930@speedy.ludd.luth.se> |
Subject: | Re: <math.h> and <libm/math.h> |
In-Reply-To: | <7458-Wed27Aug2003200336+0300-eliz@elta.co.il> "from Eli Zaretskii |
at Aug 27, 2003 08:03:36 pm" | |
To: | djgpp-workers AT delorie DOT com |
Date: | Wed, 27 Aug 2003 20:27:09 +0200 (CEST) |
X-Mailer: | ELM [version 2.4ME+ PL78 (25)] |
MIME-Version: | 1.0 |
X-MailScanner: | Found to be clean |
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 |
According to Eli Zaretskii: > > From: <ams AT ludd DOT luth DOT se> > > What should be done? Should <libm/math.h> be updated according to > > <math.h>? > > I think we should simply modify include/libm.h so that it works both > for libc.a nd for libm.a (when compiling the libraries _and_ when > compiling prfograms that use the libraries). Then we could have > <libm/math.h> include <math.h> (for back-compatibility) and do nothing > else. Sounds great. FWIW, I have tried: 1. using <math.h> instead of <libm/math.h> and got many undefined things. 2. making libm source files use the C99 nan and inifinity stuff (i. e. removing the definitions of them from libm's makefile) and got a non-compiling complete mess. > Any takers? Looks like much work. Right, MartinS
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |