[Patches] [ python-Patches-968728 ] Py_HUGE_VAL HUGE_VAL HUGE undefined

Thu Dec 23 21:25:12 CET 2004

Patches item #968728, was opened at 2004-06-08 09:48
Message generated for change (Comment added) made by mwh
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: Michael Hudson (mwh)
Date: 2004-12-23 20: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 18: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 18: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 17: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 15: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 20: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