lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: [lmi] Unit test for C99 round()


From: Vadim Zeitlin
Subject: Re[2]: [lmi] Unit test for C99 round()
Date: Fri, 13 Jun 2008 02:26:13 +0200

On Sat, 07 Jun 2008 03:37:37 +0000 Greg Chicares <address@hidden> wrote:

GC> I don't have a compiler that conforms fully to C99 Annex F (and
GC> therefore defines __STDC_IEC_559__). If you have one,

 I don't really know if I have a _fully_ conforming compiler but I do have

/* We do support the IEC 559 math functionality, real and complex.  */
#define __STDC_IEC_559__>--->---1
#define __STDC_IEC_559_COMPLEX__>---1

in /usr/include/features.h on my system. I suspect that determining how
real the claim above is is not going to be trivial though.

GC> and want to write and validate __STDC_IEC_559__ support for every place
GC> in lmi that mentions or should mention that macro, then of course that
GC> would be welcome.

 I also guess it wouldn't be a very high priority, if only because you had
presumably done it already for x86-specific code and as long as it works
there is no compelling reason to use C99 functionality.

GC> In that case, I don't see how a separate LMI_X86_FP macro would
GC> be useful. We'd just write
GC> 
GC>   #ifdef __STDC_IEC_559__
GC>       // Pure C99 code.
GC>   #elif defined LMI_X86
GC>       // Platform-specific alternative if C99 unsupported.
GC>   #else ...
GC> 
GC> and everything would just work, right?

 This is, of course, the simplest possibility but this supposes that we're
sure that C99 code works 100% correctly.

GC> Or maybe you intend such a macro to be only temporary scaffolding?

 Yes, although as usual temporary doesn't necessarily means short-lived.
The idea was to keep __STDC_IEC_559__ code in LMI (instead of e.g. removing
it completely as it would be a pity if we ever need to build it on non-x86)
but to make it possible to easily disable it for release builds on x86
hardware.

GC> Otherwise, here's an idea we can fall back on, which should leave
GC> the system in a consistent and correct state. First, revert the
GC> 20080602T1804Z and 20080606T2049Z changes; then run this command
GC> to use '(0 && defined __STDC_IEC_559__)' uniformly as the only
GC> __STDC_IEC_559__ conditional:

 Basically I propose have a single central LMI_X86_FP definition as an
alternative to replacing multiple "#ifdef __STDC_IEC_559__" tests with
(ugly IMHO) "#if 0 && defined(__STDC_IEC_559__)". For the platforms we
currently use the net effect is the same but:

1. My solution allows to at least compile LMI on non-x86 platforms
   (although it might not work 100% correctly, this would need more effort
   but it would be easier to produce it if at least the compilation test
   succeeds and so e.g. the unit tests can run)

2. Reverting your change is simple enough but not as simple as changing
   a single define in one file. And I just dislike running sed scripts on
   the entire code base like this, it always seems fool proof but sometimes
   it happens to introduce unnoticed problems (of course, in this
   particular case it does seem fool proof but then I had said it before)

3. I believe using LMI_X86_FP is more self-documenting than the unusual
   "0 && defined" construct.

 But, again, at semantic level the 2 approaches do the same thing.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]