[Michael Hudson]
> I doubt anyone else is reading this by now, so I've trimmed quotes
> fairly ruthlessly :)
Damn -- there goes my best hope at learning how large a message gmail
can handle before blowing up <wink>. OK, I'll cut even more.
[Michael]
>>> Can't we use the stuff defined in Appendix F and header <fenv.h> of
>>> C99 to help here? I know this stuff is somewhat optional, but it's
>>> available AFAICT on the platforms I actually use (doesn't mean it
>>> works, of course).
[Tim]
>> It's entirely optional part of C99.
> Hmm, is <fenv.h> optional? I'm not finding those words. I know
> Appendix F is.
fenv.h is required, but the standard is carefully worded so that
fenv.h may not be of any actual use. For example, a conforming
implementation can define FE_ALL_EXCEPT as 0 (meaning it doesn't
define _any_ of the (optional!) signal-name macros: FE_DIVBYZERO,
etc). That in turn makes feclearexcept() (& so on) pretty much
useless -- you couldn't specify any flags.
If the implementation chooses to implement the optional Appendix F,
then there are stronger requirements on what fenv.h must define.
>> Python doesn't require C99.
> Sure. But it would be possible to, say, detect C99 floating point
> facilities at ./configure time and use them if available.
Yes.
>> The most important example of a compiler that doesn't support any of
>> that stuff is Microsoft's, although they have their own MS-specific
>> ways to spell most of it.
> OK, *that's* a serious issue.
>
> If you had to guess, do you think it likely that MS would ship fenv.h
> in the next interation of VC++?
Sadly not. If they wanted to do that, they had plenty of time to do
so before VC 7.1 was released (C99 ain't exactly new anymore). As it
says on
http://en.wikipedia.org/wiki/C_programming_language
MS and Borland (among others) appear to have no interest in C99.
In part I expect this is because C doesn't pay their bills nearly so
much as C++ does, and C99 isn't a standard from the C++ world.
>>> In what way does C99's fenv.h fail? Is it just insufficiently
>>> available, or is there some conceptual lack?
>> Just that it's not universally supported. Look at fpectlmodule.c for
>> a sample of the wildly different ways it _is_ spelled across some
>> platforms.
> C'mon, fpectlmodule.c is _old_. Maybe I'm stupidly optimistic, but
> perhaps in the last near-decade things have got a little better here.
Ah, but as I've said before, virtually all C compilers on 754 boxes
support _some_ way to get at this stuff. This includes gcc before C99
and fenv.h -- if the platforms represented in fpectlmodule.c were
happy to use gcc, they all could have used the older gcc spellings
(which are in fpectlmodule.c, BTW, under the __GLIBC__ #ifdef). But
they didn't, so they're using "minority" compilers. I used to write
compilers for a living, but I don't think this is an inside secret
anymore <wink>: there are a lot fewer C compiler writers than there
used to be, and a lot fewer companies spending a lot less money on
developing C compilers than there used to be.
As with other parts of C99, I'd be in favor of following its lead, and
defining Py_ versions of the relevant macros and functions. People on
non-C99 platforms who care enough can ugly-up pyport.h with whatever
their platform needs to implement the same functionality, and C99
platforms could make them simple lexical substitutions. For example,
that's the path we took for Python's C99-workalike Py_uintptr_t and
Py_intptr_t types (although those are much easier to "fake" across
non-C99 platforms).
>> A maze of #ifdefs could work too, provided we defined a
>> PyWhatever_XYZ API to hide platform spelling details.
> Hopefully it wouldn't be that bad a maze; frankly GCC & MSVC++ covers
> more than all the cases I care about.
I'd be happy to settle for just those two at the start, As with
threading too, Python has suffered from trying to support dozens of
unreasonable platforms, confined to the tiny subset of abilities
common to all of them. If, e.g., HP-UX wants a good Python thread or
fp story, let HP contribute some work for a change. I think we have
enough volunteers to work out good gcc and MSVC stories -- although I
expect libm to be an everlasting headache (+ - * are done in HW and
most boxes have fully-conforming 754 semantics for them now; but there
are no pressures like that working toward uniform libm behaviors;
division is still sometimes done in software, but the divide-by-0 is
check is already done by Python and is dead easy to do).
--
http://mail.python.org/mailman/listinfo/python-list
