(sending again as plain text.)
On Fri, Feb 24, 2023 at 10:02 AM enh <enh@xxxxxxxxxx> wrote:
>
>
>
> On Thu, Feb 23, 2023 at 1:38 PM Jakub Wilk <jwilk@xxxxxxxxx> wrote:
>>
>> * enh <enh@xxxxxxxxxx>, 2023-02-22 12:42:
>> > The
>> >+.BR fseeko ()
>> >+end
>>
>> s/end/and/
>
>
> ack. will fix.
>
>>
>> >+.BR ftello ()
>> >+functions are similar, except that the
>>
>> "similar, except..." sounds awkward to me. (And it's not the wording
>> fseeko.3 used.)
>
>
> sounds right to me, and seems widely used in existing pages though? strncmp(), for example. ("same, except" is also used in existing pages, but seems less common.)
>
> but at a higher level (the "not the wording fseeko.3" used) i vacillated there between "just copy" and "try to improve" because i have two problems i'm trying to solve:
>
> 1. someone (rob) who knows the c library about as well as anyone i know who _isn't_ a c library maintainer themselves wasn't aware of fseeko()/ftello(), and the existing fseek() page misled them into thinking that fsetpos()/fgetpos() was their only option.
>
> 2. in 2023 where most people assume sizeof(long)*8 == 64, a lot of people don't understand why fseek()/ftell() isn't "good enough". my initial version of the patch talked more about ILP32 systems and LLP64 systems (aka "Windows") where "long" isn't equivalent to "int64_t". (but the need to talk about _FILE_OFFSET_BITS too made the whole section a bit unwieldy.)
>
> any version of this patch fixes #1.
>
> fixing #2 well is the trickier part, and i'm curious if there are any other opinions there before i send out a new version of the patch?
>
>>
>> --
>> Jakub Wilk
