[Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE
undefined
SourceForge.net
noreply at sourceforge.net
Thu Feb 10 04:45:35 CET 2005
Patches item #968728, was opened at 2004-06-08 10:48
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Michael Schloh von Bennewitz (michaesc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Py_HUGE_VAL HUGE_VAL HUGE undefined
Initial Comment:
In Python 2.3.4 (as well as the trunk revision on CVS), Py_HUGE_VAL
is conditionally defined as HUGE_VAL. On at least Solaris 10 x86 and
Solaris 10 SPARC, this causes a build failure.
I'm ashamed to say that I wasn't able to 100% diagnose this problem (I
didn't have time). My first guess was that somehow HUGE_VAL was not
getting properly defined on Solaris 10 due to its rewritten
/usr/include/iso/math_iso.h file (now conditionally defining HUGE_VAL
depending on a _STDC_C99 and _XOPEN_SOURCE definition).
Because I noticed that the identifier HUGE is unconditionally defined
on Solaris 10 and seemingly all earlier Solaris releases, I tried using
that instead and the build problem disappeared.
You can make your own conclusion as to whether my fix is correct, or if
there is a better way to solve this problem. There may be a faulty
assumption made by configure or in some Makefile of how the compiler
is being used, or maybe python depends on a certain GCC release.
CC: GCC 3.4.0
CXX: GCC 3.4.0
CFLAGS: -O2 -pipe
CXXFLAGS: -O2 -pipe
CPPFLAGS: None
Make: GNU Make 3.80
LDFLAGS: None
mich at dev:/tmp/Python-2.3.4$ ./configure --prefix=/cw
checking MACHDEP... freebsd4
checking EXTRAPLATDIR...
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
...
The OpenPKG Python package and patch:
http://cvs.openpkg.org/dir?d=openpkg-src/python
http://cvs.openpkg.org/rlog?f=openpkg-src/python/python.patch
Lots of luck, and thanks for maintaining Python.
Regards,
Michael, OpenPKG
http://www.openpkg.org/
----------------------------------------------------------------------
>Comment By: Martin v. Löwis (loewis)
Date: 2005-02-10 04:45
Message:
Logged In: YES
user_id=21627
In GCC, __builtin_huge_val() is indeed a constant
expression. The compiler just knows this function, and knows
that the function call is indeed a constant expression. The
compiler is entitled to that conclusion: __builtin_huge_val
is a reserved name, and the compiler can associate any
semantics with a reserved name (e.g. treat it as a keyword -
just like sizeof(), which also yields a constant).
(As a side note: you take the address of __builtin_huge_val,
but that gives a linker error, as this function is nowhere
implemented; the implementation of it in the compiler
returns +INF)
The header itself is certainly compliant - one just has to
use the "right" compiler, i.e. Sun cc (aka SunPRO, aka
Forte, aka whatever they're calling it now). Apparently,
__builtin_huge_val is a constant (not a function) in Sun CC
- and that is also standards compliant.
I just remarked in #1116722 that this is a gcc bug, which
should use its fixincludes magic to add the missing
parentheses, or replace the definition of HUGE_VAL
altogether with something else.
Of course, the gcc bug shows only up if _XOPEN_SOURCE is
defined (or _STDC_C99 or __C99FEATURES__) - otherwise, gcc
will probably provide its own definition of HUGE_VAL. So it
is likely that none of the gcc developers has noticed yet,
as you need both Solaris 10 *and* a software that turns on
_XOPEN_SOURCE.
You might want to coordinate with casevh to report the gcc
bug and come up with a patch, as outlined in #1116722.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-12-23 21:25
Message:
Logged In: YES
user_id=6656
Maaybe the parens are meant to be present in the macro definition?
That would make some kind of sense, apart from probably still not
meeting the letter of the standard (don't think the result of a function call
is a "constant expression", somehow).
----------------------------------------------------------------------
Comment By: Chris P. Ross (cross)
Date: 2004-12-23 19:40
Message:
Logged In: YES
user_id=12814
Oops. My bad. I failed to mention that I'm using gcc 3.4.x
on Solaris 10. I assume those options are for the Forte
suite (or whatever they're calling it now).
Hmm. I wonder how to tell sun that they're header isn't
compliant? I wonder if it fails in the same way with Forte?
I should try to find out... It *is* a beta OS after-all. :-)
Thanks!
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-12-23 19:09
Message:
Logged In: YES
user_id=31435
>From C99:
"""
The macro
HUGE_VAL
expands to a positive double constant expression, not
necessarily representable as a float.
...
(footnote) HUGE_VAL, HUGE_VALF, and HUGE_VALL can be
positive infinities in an implementation that
supports infinities.
"""
Of course a function pointer is not "a positive double
constant expression", so doesn't meet the standard's
requirements.
Some Googling suggested that the "-Xc or -Xa compliation
options" may be needed to get standard behavior on Solaris,
but that's just hearsay and I really have no idea. Reports of
HUGE_VAL creating compilation problems on Solaris for other
projects are also easy to find.
----------------------------------------------------------------------
Comment By: Chris P. Ross (cross)
Date: 2004-12-23 18:43
Message:
Logged In: YES
user_id=12814
Hi. I found this today as well. However, a little research
shows that what it's defined to (__builtin_huge_val) is
actually a function pointer, not a number. So, if I changed
Py_HUGE_VAL to be #def'd to HUGE_VAL(), it worked just find
on my Solaris 10 machine.
What does the c89 and c99 spec say that HUGE_VAL macro
should be? A number? Or is having it be a function
reference legal?
----------------------------------------------------------------------
Comment By: Hye-Shik Chang (perky)
Date: 2004-07-17 16:05
Message:
Logged In: YES
user_id=55188
This doesn't look like a bug in Python per Tim's comment.
(Reviewed by Seo Sanghyeon and me at KLDP CodeFest)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-06-08 21:02
Message:
Logged In: YES
user_id=31435
I don't see a reason to call this a Python bug. The C89 and
C99 standards both require that math.h supply the HUGE_VAL
macro. If the compilation system you're using doesn't do so,
it's a bug in that system, and should be fixed there. Python
doesn't ask for much, but does require an ANSI C compiler.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968728&group_id=5470
More information about the Patches
mailing list