[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Records longer than INT_MAX mishandled
From: |
Miguel Pineiro Jr. |
Subject: |
Re: Records longer than INT_MAX mishandled |
Date: |
Wed, 05 May 2021 14:04:19 -0400 |
User-agent: |
Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 |
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.
>