Why is MAXINT doubly defined in system include files

[Marc Ferry]

I already posted this mail in comp.sys.hp and comp.sys.hp.hpu x but had
no response. As this problem might be present on other OSes than HP-UX
10.20, I crosspost it here, in the hope of getting an answer.

*************** **********

In C/C++ system include files on HP-UX 10.20,
/usr/include/values.h defines macro MAXINT as (~HIBITI)
/usr/include/sys/param.h defines macro MAXINT as 0x7fffffff

Why is that so ?
I understand that the final value is the same.
But as my program happens to include both values.h and param.h, I get
the following error (future) with aCC:

Error (future) 129: "/usr/include/values.h", line 27 # Redefinition of
macro 'MAXINT' differs from previous definition
at ["/usr/include/sys/param.h", line 45].
#define MAXINT (~HIBITI)
^^^^^^
Warning: 1 future errors were detected and ignored. Add a '+p'
option to detect and fix them before they become fatal errors in a
future release. Behavior of this ill-formed program is not guaranteed to
match that of a well-formed program

I cannot change the libraries (which include values.h and param.h) used
by my program because I don't own them. I don't want to use compile
option +W129 because it would suppress this particular future error but
also all the others.

Is there a simple trick to avoid this error ?

I noticed that the problem has been fixed on HP-UX 11i. Indeed, values.h
defines MAXINT only if it is not already defined:
#ifndef MAXINT
#define MAXINT ((int)(~(unsign ed int)HIBITI))
#endif /** MAXINT **/

Thanks for your advice.
Marc Ferry

[tom_usenet]

On Mon, 13 Oct 2003 15:26:05 +0200, Marc Ferry
<mf********@rd. francetelecom.c om> wrote:

tom_usenet wrote:

<mf********@rd. francetelecom.c om> wrote:

I already posted this mail in comp.sys.hp and comp.sys.hp.hpu x but had
no response. As this problem might be present on other OSes than HP-UX
10.20, I crosspost it here, in the hope of getting an answer.

This newsgroup is for issues relating to ISO standard C++ (or C for
the crosspost). This clearly isn't the right place,
comp.unix.progr ammer would be slighly closer. But if you can't get an
answer on HP related newsgroups, you should contact HP directly, since
there's no where else to post such questions.

Don't you mix up with comp.std.c++ ?

Nope: http://www.parashift.com/c++-faq-lit...t.html#faq-5.9

Presumably a bug. Have you asked HP?

Not yet. I am going to look for my support contract with HP (if I have one).

Thanks for your advice.

Either you're going to have to edit the system headers yourself, or
you're going to have to edit the 3rd party library, or you're going to
have to get a patch from HP to fix the system headers for you. The 3rd
option sounds best to me...

Tom

[Nick Austin]

On Mon, 13 Oct 2003 15:22:14 +0200, Marc Ferry
<mf********@rd. francetelecom.c om> wrote:

Nick Austin wrote:

<mf********@rd. francetelecom.c om> wrote:

In C/C++ system include files on HP-UX 10.20,
/usr/include/values.h defines macro MAXINT as (~HIBITI)
/usr/include/sys/param.h defines macro MAXINT as 0x7fffffff

Why is that so ?
I understand that the final value is the same.
But as my program happens to include both values.h and param.h, I get
the following error (future) with aCC:

Error (future) 129: "/usr/include/values.h", line 27 # Redefinition of
macro 'MAXINT' differs from previous definition
#include <values.h>
#undef MAXINT
#include <sys/param.h>

Question: Where should I put these lines ?

In the files that include <values.h> and <param.h>.

If you cannot modify either of these files then the process needs
to be applied recursively; so if <foo.h> contains #include <values.h>
then find the file that contains #include <foo.h> and include the
#undef there.
Remember: I cannot change the includes done by the libraries because I
don't own them (external product). And I doubt that both values.h and
param.h includes are in the same library.

This highlights a design issue.

When designing and implementing header files for a third party you
need rules to avoid namespace clashes. If this is not possible an
alternative is to split the application into translation units.
Each translation unit is designed so that it only needs to include
definitions from one set of header files.

Nick.