This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Py_HUGE_VAL HUGE_VAL HUGE undefined
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: cross, hyeshik.chang, loewis, michaesc, mwh, tim.peters
Priority: normal Keywords: patch

Created on 2004-06-08 08:48 by michaesc, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python.patch michaesc, 2004-06-08 08:48 Include/pyport.h repair for missing HUGE_VAL
Messages (8)
msg46138 - (view) Author: Michael Schloh von Bennewitz (michaesc) Date: 2004-06-08 08:48
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@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/
msg46139 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-06-08 19:02
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.
msg46140 - (view) Author: Hyeshik Chang (hyeshik.chang) * (Python committer) Date: 2004-07-17 14:05
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)
msg46141 - (view) Author: Chris P. Ross (cross) Date: 2004-12-23 17:43
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?

msg46142 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-12-23 18:09
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.
msg46143 - (view) Author: Chris P. Ross (cross) Date: 2004-12-23 18:40
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!
msg46144 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2004-12-23 20:25
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).
msg46145 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-02-10 03:45
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.
History
Date User Action Args
2022-04-11 14:56:04adminsetgithub: 40362
2004-06-08 08:48:40michaesccreate