Re: Bug#807743: RFS: filters/2.55-1 [ITA] - collection of filters, including B1FF and the Swedish Chef
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-12-12 at 16:15, Marius Gavrilescu wrote:
> Hello,
>
> Thanks for the feedback. I'll send patches to upstream and ask him
> to (officially) release 2.55 with these changes.
>
> Gianfranco Costamagna <locutusofborg@debian.org> writes:
>> cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not
>> find or open any of the paths given.' [scramble.c:175]: (error)
>> Memory leak: word
I acknowledge this one, although it's such a minor leak that I'm not
sure the code to free it is worth the while; it's literally "found
invalid conditions before doing anything, shutting down the program".
Easy to add a free before returning, but I believe there's a school of
thought that says that doing so is a waste of code...
>> [scramble.c:180]: (error) Common realloc mistake: 'word' nulled
>> but not freed upon failure
>
> Fixed.
Could I have the patch for that? I wrote scramble, and although I
haven't touched it in years and it's carried in filters nowadays, I'd
prefer to keep my local copy in sync with downstream changes when and as
appropriate.
I'm not completely sure I see the problem with this one; I've considered
a few possibilities, but I don't see how reallocating (and shortening) a
zeroed buffer for reuse is a memory leak or any other type of issue.
I also don't see where the free should be done, since this buffer is
reused every time the loop runs through; freeing the buffer would just
require immediately allocating it again. (I suppose the 'realloc(),
work, loop' could be replaced by 'malloc(), initialize, work, free(),
loop', but that seems inefficient at best.)
Could someone explain what the mistake is (perhaps offlist, since it
isn't really on-topic)?
- --
Andrew J. Buehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJWbLekAAoJEASpNY00KDJrAZ0P/1pwLBN83vEaMUeFgb8eVweX
pk3HjukO//Gx7Aup0iyF/FgTfgNLhpQb6wBJft58jT5vljlYUgLlmPz9DkV9gfr6
eB7lD3WMkBEhfsDJqq1nx4buz46Sd8gxvF3h3nzxv65VWN0Ow+XYP6rIxKd0ANmy
C8FI/NYDpnzxDJ9NNcgMR84fpHZS4lVXJcND17mM5/NY3+F2GWxUBUGvrT5UBbUC
WeSsod+HZzvNll0wh/7HQ17/dRQND6mi/C4o44MyzI/zVtwljUSiDRo3y/c2TAhI
nrG124RjkTkB0C6a92b4dy5QUb3Q9Cw16pihnz+UGf1GMrc9oF54gMuHxWpUMQ82
2zTf3NwXgV4arPh9J0DXVYw5HyyFMVGEfalEkl3LR+wradv1EB1FmUf1SyrmMJHK
eviPqJoU4RFAtv+CHDB75N9E4L921rfoxfpYx/djynvKm4n9a6HTwrECCFOs7yEV
uwnoAORkUKlsjtQ7JURUP/5/YNGZXiet6BrPSiLKeyH4S5GYxkGSbfxUtcpjrHeU
+5pD82VqDUELii++2a+aaSraiCMhSr7cSnZCgcj6Avk7GHHhcamCmjJYTPNfRLh6
vyCGr1z8eI80/Ram4qgipkZ2amThGVIP5A+s0BISCctNhRc2mI13FVC+IERcI+6s
bpx2xGGqSLXXiclWgcSo
=xrRi
-----END PGP SIGNATURE-----
Reply to: