Bug 357941 - arith.h defines INT_MAX when it shouldn't
arith.h defines INT_MAX when it shouldn't
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: graphviz (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jima
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-30 05:48 EDT by Tim Niemueller
Modified: 2009-07-14 13:01 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:01:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Niemueller 2007-10-30 05:48:57 EDT
Description of problem:
arith.h contains:
#ifndef INT_MAX
#define INT_MAX         ((int)(~(unsigned)0 >> 1))
#endif

This conflicts with other declarations. See the following code:
#include <graphviz/gvc.h>
#include <map>

int
main(int argc, char **argv)
{
}


Suddenly the include order matters here. Compiling the given code with "gcc -o
graphvizbug graphvizbug.cpp" leads to the following error:
In file included from /usr/include/limits.h:153,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h:122,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h:11,
                 from
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/climits:50,
                 from
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algobase.h:66,
                 from
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:66,
                 from
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/map:65,
                 from graphvizbug.cpp:3:
/usr/include/bits/xopen_lim.h:95:6: error: missing binary operator before token "("
/usr/include/bits/xopen_lim.h:98:7: error: missing binary operator before token "("

The code in xopen_lim.h compares INT_MAX to a specific integer value (which is
included down the road by the inclusion of <map>. Using braces here leads to a
syntax error, the braces come from the arith.h INT_MAX declaration.

Version-Release number of selected component (if applicable):
graphviz-2.12-8.fc7
graphviz-devel-2.12-8.fc7

How reproducible:
Always

Steps to Reproduce:
1. Put the code mentioned above into a file
2. Try to compile
3. See error message
  
Actual results:
Does not compile.

Expected results:
Should compile without any ordering constraints on the includes.

Additional info:
graphviz/arith.h should include limits.h for proper definition of INT_MAX etc.
and should not define it by itself.
Comment 1 Jima 2007-12-03 15:55:26 EST
Sorry for the delay in my response.

I'm bumping this upstream, as I don't feel this is the kind of change a distro
should be making.

John, any rationale for this either way?
Comment 2 John Ellson 2007-12-03 21:56:24 EST
arith.h will include limits.h if you have HAVE_LIMITS_H defined. e.g. by using a
configure.ac test:    AC_CHECK_HEADERS(limits.h)

I'm willing to listen to better ways of solving this cross-platform problem.  
This was my solution to compiling on IRIX, SunOS, AIX, HPUX, as well as Linux.
Comment 3 Tim Niemueller 2007-12-04 07:26:34 EST
Is there no limits.h on at least one of IRIX, SunOS, AIX, HPUX? As limits.h
suggests it is a requirement per "ISO C99 Standard: 7.10/5.2.4.2.1 Sizes of
integer types <limits.h>".

We are not using autoconf but another build system. This looks like the autoconf
tools are a soft dependency for graphviz. Actually it still depends on the
include order because if I remember correctly you have to include the generated
config.h to get the HAVE_* flags?

Maybe it would be an option to define constants like GV_INT_MAX. If
HAVE_LIMITS_H is found limits.h is included. Then _LIBC_LIMITS_H_ is checked and
if set GV_INT_MAX is defined as INT_MAX, otherwise it is set to the value that
you set if INT_MAX is not defined currently. This way there is no conflict and
even if HAVE_LIMITS_H is not set it works without conflicts if someone else
includes limits.h before or after the arith.h header file.
Comment 4 Bug Zapper 2008-05-14 10:54:57 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Tim Niemueller 2008-05-14 11:25:59 EDT
This is still an issue on F-9. John, any comments on my suggestions from comment #3?
Comment 6 John Ellson 2008-05-15 07:41:08 EDT
I'm trying a change upstream to unconditionally include limits.h and values.h
in arith.h.    We'll see what this breaks.
Comment 7 Tim Niemueller 2008-09-30 07:20:42 EDT
Has there been any progress on this issue?
Comment 8 John Ellson 2008-10-02 19:48:17 EDT
I've forgotten what my conclusion was on this, but it looks as though I made one change.   limits.h is now included unconditionally by arith.h before testing  #ifndef INT_MAX, so it looks to me like this should work if limit.h is 
included again either before or after arith.h.

If limits.h doesn't exist on SGI's then i don't understand why I haven't heard complaints about this.

Could you test with rpms from www.graphviz.org to see if this problem still exists?
Comment 9 Bug Zapper 2009-06-09 19:08:10 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Tim Niemueller 2009-06-11 16:08:19 EDT
The problem is solved with the current graphviz.org rpms (2.22.2). Are there any plans to include them in Fedora anytime soon? The graphviz packages in Fedora tend to lag behind a long time.
Comment 11 Bug Zapper 2009-07-14 13:01:07 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.