64-bit stat (or not) in 32-bit Fedora binaries

[Petr Pisar]

On 2013-02-19, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
> (1) Just ensuring the code is compiled with -DFILE_OFFSET_BITS=64 is
> sufficient to ensure the 32 bit stat will never be called, right?
>
I think so.

> (2) If my code never mentions st_ino, it's safe?
>
>   [I assume the answer to this is *no* because you seem to be saying
>   that -EOVERFLOW could be returned from an innocent-looking stat
>   call, even if the code never looks at st_ino.]
>
No. st_size is the same story. In addition if a library passes struct stat to
an application and they are compiled with different FILE_OFFSET_BITS,
then the structures will not be compatible (different padding etc.) and
can corrupt data.

> (3) For my code that uses st_ino, I need to ensure this is never
> assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
>
Yes. If possible, keep stuck to off_t.

> (5) With -DFILE_OFFSET_BITS=64, is st_ino a 64 bit value?
>
That's implementation specific. I would not rely on that.

> Also a note that the current man page for stat(2) doesn't mention this
> problem, doesn't mention that EOVERFLOW could be returned in this
> surprising situation, and also has an example that casts st_ino to a
> long which I assume would be unsafe behaviour on a 32 bit
> architecture.  These are all bugs that the man-pages maintainers would
> no doubt be interested in.
>
My stat(2) and stat(3p) talks about EOVERFLOW clearly:

EOVERFLOW
      (stat()) path refers to a file whose size cannot be  represented
      in  the type off_t.  This can occur when an application compiled
      on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat()
      on a file whose size exceeds (1<<31)-1 bits.

EOVERFLOW
      A value to be stored would overflow one of the  members  of  the
      stat structure.

-- Petr