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

[David Woodhouse]

On Tue, 2013-02-19 at 17:09 +0100, Jakub Jelinek wrote:
> On Tue, Feb 19, 2013 at 05:04:43PM +0100, Florian Weimer wrote:
> > On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
> > >On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> > >>>(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.)?
> > >>
> > >>To be safe I'd use it in an u64 type, I guess.  The *internal* kernel stat
> > >>structure uses u64:
> > >
> > >That would be wrong.  To store st_ino values, you should be using the ino_t
> > >type, like for file sizes/offsets (st_size, seeking, etc.) you should be
> > >using off_t.  Both of these types depend on _FILE_OFFSET_BITS macro.
> > 
> > You can't use ino_t and off_t in public header files because of that
> > _FILE_OFFSET_BITS dependency.  At least in such header files, using
> > explicit 64-bit types (uint64_t, presumably) is the way to go.
> 
> You can use it in public header files just fine, if you mean using it for
> library ABIs, then you can use ino64_t or off64_t, which is certainly
> cleaner than using uint64_t.

Or just use ino_t and off_t and add a compile-time error if they
*aren't* 64-bits.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130308/ed529109/attachment.bin>