Re: Records longer than INT_MAX mishandled

[Miguel Pineiro Jr.]

Sure. Go ahead and send me the necessary info.

On Wed, May 5, 2021, at 2:21 AM, arnold@skeeve.com wrote:
> At first glance this all looks reasonable.  It's a big enough
> change that I'll need you to sign paperwork assigning copyright to the
> FSF. Are you willing to do that?
> 
> If so I'll send more info in private mail.
> 
> Thanks!
> 
> Arnold
> 
> "Miguel Pineiro Jr." <mpj@pineiro.cc> wrote:
> 
> > Hi, Arnold.
> >
> > Here's a crack at size_t records.
> >
> > Starting at the bottleneck, get_a_record gains a new parameter of type
> > pointer to size_t. While the function's return type remains an int,
> > the meaning of non-negative values is different.
> >     
> > Return Value           Unpatched             Patched
> > ------------        --------------        --------------
> >           -2        Retryable Read        Retryable Read
> >          EOF        End of File           End of File
> >            0        Record Length         Valid Record
> >   1..INT_MAX        Record Length         <unused>
> >
> > 0 thru INT_MAX had been record lengths. This patch changes 0 to mean
> > there's a valid record whose length is stored in the address pointed to
> > by the new parameter. Positive values are no longer returned.
> > 
> > inrec, do_getline, do_getline_redir, and set_record now use only size_t
> > record lengths.
> > 
> > The extension api wasn't altered. If it should match the capabilities
> > of the internal reader, it'll need some tending to.
> > 
> > I did not visit any code that wasn't directly affected by get_a_record's
> > modification, so it's possible that an audit may find bits in need
> > of attention.
>