Tim Peters <[EMAIL PROTECTED]> writes: > [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.
Heh. > [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. Makes sense. > >> 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. This also makes sense, in a slightly depressing way. > >>> 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). Um, well, no, not really. The stuff under __GLIBC___ unsurprisingly applies to platforms using the GNU project's implementation of the C library, and GCC is used on many more platforms than just that (e.g. OS X, FreeBSD). This is all part of the "what exactly are you claiming supports 754, again?" game, I guess. Even given that, the glibc section looks mighty Intel specific to me (I don't see why 0x1372 should have any x-architecture meaning). Now that GCC supports, or aims to support, or will one day support C99 I think you're right in that any GCC-using code can use the same spelling. One thing GCC doesn't yet support, it turns out, is the "#pragma STDC FENV_ACCESS ON" gumpf, which means the optimiser is all too willing to reorder feclearexcept(FE_ALL_EXCEPT); r = x * y; fe = fetestexcept(FE_ALL_EXCEPT); into feclearexcept(FE_ALL_EXCEPT); fe = fetestexcept(FE_ALL_EXCEPT); r = x * y; Argh! Declaring r 'volatile' made it work. > 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. Indeed. Also, less architectures and less C libraries. > 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. Makes sense! > >> 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 Well, yes. I think a 'thin wrapper' approach like some of the os module stuff makes sense here. Cheers, mwh -- I've reinvented the idea of variables and types as in a programming language, something I do on every project. -- Greg Ward, September 1998 -- http://mail.python.org/mailman/listinfo/python-list
