autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf problem with large files on HP-UX?


From: Paul Eggert
Subject: Re: autoconf problem with large files on HP-UX?
Date: Tue, 6 Feb 2001 12:34:46 -0800 (PST)

> Date: Tue, 6 Feb 2001 12:59:05 -0700 (MST)
> From: Bob Proulx <address@hidden>

> > + /* Check that off_t can represent 2**63 - 1 correctly.
> > +    We can't simply define LARGE_OFF_T to be 9223372036854775807,
> > +    since some C++ compilers masquerading as C compilers
> > +    incorrectly reject 9223372036854775807.  */
> 
> It may be that some C++ compilers masquerade as C compilers such as
> GCC.  But I disagree about "incorrectly reject large integers".  Also,
> this problem has nothing to do with C++ and is basically an ANSI C
> issue.  I am guessing that comment relates to a slightly different
> issue.  I believe it is correct behavior to reject immediate data that
> overflows the data size.

Yes it is.  And if the target cannot represent 9223372036854775807, it
is correct for the C compiler to reject that program.  But that is
what we want to happen here.

Here's the actual problem that I was referring to.  Suppose you have a
host with 32-bit int and long, 64-bit long long, and 64-bit off_t.  On
such a system, the C99 standard says that 9223372036854775807 is a
valid constant of type long long.  However, I've been told that C++
has a different rule: it says that 9223372036854775807 is not valid
constant on such a host, because 9223372036854775807 is not a valid
'int'.

With C++, you have to write 9223372036854775807ULL; this works under
C99 but is not portable to K&R C or C89, so I would rather not use it
here.

The problem arises when you have a compiler that claims to be a C
compiler but actually enforces the C++ rules.  Such a compiler will
reject a program containing plain 9223372036854775807 no matter how
it's compiled, so "configure" will incorrectly conclude that the
compiler does not support large files.

When I first heard about the problem, I was inclined to dismiss it,
under the theory that a C compiler that incorrectly rejects
9223372036854775807 is likely to have other problems that cause it to
break with large files.  But I have been told that this problem is
common in some parts of the world, so it's worthwhile to address it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]