On Montag, 22. April 2024 09:27:47 CEST Paul Eggert wrote: > > - off_t changes depending on whether gl_LARGEFILE is in use or not; > > thus it's a bad idea to use it in the API of any shared library or > > (more generally) any independently-built component. > > That ship sailed long ago, I'm afraid. That is, any API depending on I/O > sizes must deal with this problem anyway, so there's nothing new here.
But dealing with this problem means to define 2 functions instead of 1. For example, ftello is a function which returns off_t, and glibc defines ftello and ftello64: $ nm --dynamic /lib/i386-linux-gnu/libc.so.6 | grep ftello | grep -v __ 0007a8e0 W ftello@@GLIBC_2.1 0007ae20 W ftello64@@GLIBC_2.1 $ nm --dynamic /lib/x86_64-linux-gnu/libc.so.6 | grep ftello | grep -v __ 0000000000088d50 W ftello@@GLIBC_2.2.5 0000000000088d50 W ftello64@@GLIBC_2.2.5 > (Also, the problem will go away soon enough anyway, as 32-bit off_t > systems will likely die out by 2038 due to time_t issues of all things....) The problem will not entirely go away then. Only one function will be needed then, but it will be platform-dependent whether its return type is 'off_t' (standardized but 32-bit on Haiku) or 'off64_t' (always 64-bit but not standardized). [1] I would like to side-step this complexity by using a typedef'ed 'zoff_t' instead of 'off_t'. > > But direct use of off_t has two problems: > > - off_t is not defined by ISO C; thus it's an odd return type for things > > like zsprintf. > > I was thinking that zsprintf should return ptrdiff_t and zprintf would > return off_t. That makes sense, indeed. I'll do that, with 'zoff_t' instead of 'off_t'. Thanks for the suggestion. > An advantage of the off_t/ptrdiff_t approach is that it does not > introduce a new type with all the confusion that would bring (there's a > reason regoff_t has been so unpopular - even glibc doesn't implement it > properly if memory serves...). I think that the problem with regoff_t was that it already had legacy uses and therefore could not move to 64 bits. A problem that we won't have with 'zoff_t'. Bruno [1] https://manpages.debian.org/unstable/manpages/off_t.3.en.html
