On Fri, Feb 24, 2023 at 10:06 AM enh <enh@xxxxxxxxxx> wrote:
>
> (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
Attachment:
0001-fseek.3-incorporate-fseeko-ftello.patch
Description: Binary data
