[flac-dev] Possible overflow of _candidate_bits in stream_encoder.c

[Martijn van Beurden]

Op ma 6 jul. 2020 om 10:22 schreef Erik de Castro Lopo <mle+la at mega-nerd.com>:
>
> Martijn van Beurden wrote:
>
> > To trigger this overflow, one has to force rice_parameter to 0
>
> Ok, that sounds dodgy.

Yes, well, it is. It could very well be that without patching, nobody
ever has a problem with this, but as the rice code is based on an
estimate, it might, perhaps. Especially if someone reenables
rice_parameter_search, which is currently marked as deprecated.
Patching it doesn't seem to affect speed in a measurable way. But I
would very well understand if these two patches are not accepted.

Attached is a patch and a PDF with a comparison of the current git
versus application of the 4 patches I sent today and yesterday. These
tests have been run on a Raspberry Pi B 3+, and as can be seen from
comparing the two files, there is quite a bit of measurement
uncertainty in decoding. It seems to me this patch doesn't change the
encoding speed, and the analyse.c patch doesn't change the decoding
speed.

Kind regards, Martijn van Beurden

P.S.: I'm sending this for the second time, sorry if it arrives twice.
It seems to me e-mails over 50kb don't get through.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Add-some-overflow-checks-for-residual-bits-calculati.patch
Type: text/x-patch
Size: 3540 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200706/840cef4a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: long set of samples 1.pdf
Type: application/pdf
Size: 19595 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20200706/840cef4a/attachment-0001.pdf>