On 2013-02-19, Richard W.M. Jones <rjones@xxxxxxxxxx> 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
