As I was removing outdated #ifdefs my eye fell on HAVE_HYPOT, and I have this very vague recollection that some old 68K Macs were the only system where hypot() wasn't in the C library. Does anyone know this for sure? If so we could remove the whole hypot() stuff... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
[Jack Jansen]
As I was removing outdated #ifdefs my eye fell on HAVE_HYPOT, and I have this very vague recollection that some old 68K Macs were the only system where hypot() wasn't in the C library.
The only comments about this in the codebase and in NEWS suggest that's so.
Does anyone know this for sure?
Perhaps God -- the rest of us run on a finite number of machines <wink>.
If so we could remove the whole hypot() stuff...
+1, including nuking Python/hypot.c. hypot() is a std C library function, so any platform without it is plain busted; and an alpha release is the only time we dare test that hypot<wink>hesis.
If so we could remove the whole hypot() stuff...
Maybe not! I don't have a copy of the C89 std here, and web searches turn up conflicting claims. My favorite C89 web site: http://www-ccs.ucsd.edu/c/ does not list hypot among the C89 functions. It's definitely required in C99. To play it safe, I expect we need to keep our own hypot after all. Would still be nice to simplify this Mac-ish part of pyport.h: #ifndef HAVE_HYPOT extern double hypot(double, double); #ifdef MWERKS_BEFORE_PRO4 #define hypot we_dont_want_faulty_hypot_decl #endif #endif #ifndef HAVE_HYPOT #ifdef __MWERKS__ #undef hypot #endif #endif While we're at it, shame Barry into cleaning this up <wink>: #ifdef __NeXT__ #ifdef __sparc__ /* * This works around a bug in the NS/Sparc 3.3 pre-release * limits.h header file. * 10-Feb-1995 bwarsaw@cnri.reston.va.us */ #undef LONG_MIN #define LONG_MIN (-LONG_MAX-1) #endif #endif
participants (2)
-
Jack Jansen
-
Tim Peters