[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Records longer than INT_MAX mishandled
From: |
arnold |
Subject: |
Re: Records longer than INT_MAX mishandled |
Date: |
Wed, 05 May 2021 00:21:12 -0600 |
User-agent: |
Heirloom mailx 12.5 7/5/10 |
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.