bug-gawk
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]