Re: AC_SYS_LARGEFILE bug in autoconf cvs 20001215

[Paul Eggert]

> Date: Wed, 20 Dec 2000 14:02:22 -0500 (EST)
> From: Pavel Roskin <address@hidden>

> 9223372036854775807l    (if sizeof(long) is big enough)
> 9223372036854775807ll   (if "long long" is supported)

We can't use "LL" because not all compilers support it.  Some
compilers have 64-bit long, so "L" will work with them; but "L" won't
work for compilers with 32-bit long and 64-bit long long.  So we can't
use "L" either.

> I fail to see how support for constants in the _compiler_ affects support
> of large files in the _library_.

If the compiler can't do 64-bit arithmetic, we can't trust the library
to do 64-bit off_t correctly.  We can't even trust the compiler to
invoke the library correctly.

Conversely, if the compiler can do 64-bit arithmetic correctly and if
it reports that off_t is at least 64 bits, then that's good enough.
Yes, the library might be buggy, but I've never encountered that in
practice.  Checking for buggy libraries would require run-time tests,
but they make cross-compiling a pain so I want to avoid them.

> > +#   define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
> > +    int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
> > +                   && LARGE_OFF_T % 2147483647 == 1)
> > +                  ? 1 : -1];
> >    ]])

> configure:1286: g++ -c -g -O2  conftest.cc >&5
> configure:1259: warning: left shift count >= width of type
> configure:1259: warning: left shift count >= width of type
> configure:1260: warning: left shift count >= width of type
> configure:1260: warning: left shift count >= width of type
> configure:1261: syntax error before `?'
> configure:1289: $? = 1

The warnings are correct: if off_t is 32 bits, you expect to see
those warnings.

What is that syntax error for, though?  I don't see any syntax error
in the code.  Perhaps there was a cut-and-paste error involving the
"+" signs from diff -u?

What happens when you try to compile the following program?

#include <sys/types.h>
/* Check that off_t can represent 2**63 - 1 correctly.
   We can't simply "#define LARGE_OFF_T 9223372036854775807",
   since some C++ compilers masquerading as C compilers
   incorrectly reject 9223372036854775807.  */
#   define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62))
int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721
                    && LARGE_OFF_T % 2147483647 == 1)
                   ? 1 : -1];

Here is what I get on Solaris 8 with GCC and with Sun's C++ compiler;
it's what I expect.  If you get the same results as me here, then I
suspect even more strongly that it was a cut-and-paste error, or an m4
quoting problem, or something like that.

$ gcc -S t.cc
t.cc:7: warning: left shift count >= width of type
t.cc:7: warning: left shift count >= width of type
t.cc:8: warning: left shift count >= width of type
t.cc:8: warning: left shift count >= width of type
t.cc:9: size of array `off_t_is_large' is negative
$ CC -S t.cc
"t.cc", line 9: Error: An array must have at least one element.
1 Error(s) detected.
$ gcc -S -D_FILE_OFFSET_BITS=64 t.cc
$ CC -S -D_FILE_OFFSET_BITS=64 t.cc
$ 

 
> If we add parens around ((off_t) 1) the warning disappears (in one case
> which should be detected) but the error is still there.

In C++, you must write (((off_t) 1) << 62) instead of ((off_t) 1 << 62)?
I find that hard to believe.  I still suspect that it was a cut-and-paste
error.