On 4/22/24 7:21 AM, Bruno Haible wrote:
dealing with this problem means to define 2 functions instead of 1.
Since Gnulib is a source library, that complexity would be needed only
for use inside object libraries - and these libraries already need to
deal with off_t issues.
(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]
You lost me there. Although I don't use Haiku, my impression is that
off_t is 64 bits on Haiku. See, for example,
<https://www.haiku-os.org/docs/api/SupportDefs_8h.html>.
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'.
True, but now that you mention off64_t it strikes me that zoff_t would
basically be off64_t, and off64_t has had its own problems: its only use
in apps is to deal with deficient libraries, and it is a pain in
libraries (where its only use is to deal with deficient apps :-). I
don't offhand see why zoff_t would do any better than off64_t has done,
or why we would need to give a new name to this unloved type.
