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
<<attachment: smime.p7s>>
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
