Bug#521257: Use of uninitialized value in bitwise or (|) at /usr/share/lintian/lib/Lintian/Command.pm line 308.
Russ Allbery wrote:
> Raphael Geissert <atomo64+debian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> writes:
>
>> I found a difference on the results of the file-info parsing:
>>
>> diff --git a/t1 b/t2
>> index 14783a7..1e3fbb1 100644
>> --- a/t1
>> +++ b/t2
>> @@ -648,4 +648,4 @@ unit_tests/urls.nocomment.ref^@
>> unit_tests/urls.notags.ref^@
>> unit_tests/valgrind.supp^@
>> unit_tests/valgrind_tests.sh^@
>> -unit_tests/virusaction-test.sh^@
>> +unit_tests/virusaction-test.s^@
>>
>> The former is from my machine, the latter is from the provided index.
>
> Where is this generated at? A nul followed by a newline is strange. Or
> was this just from debugging code?
This is what collection/file-index pipes to xargs which later calls file(1).
Since unit_tests/virusaction-test.s does not exist file(1) fails which
returns the error code that later aborts the check of that package.
>
>> Although there's definitely a bug in how the index is generated, I found
>> another bug, in file-info: chop was being used instead of chomp;
>> attached mbox corrects that (and should probably workaround the index
>> file generation bug).
>
> chomp is better coding style, but it should be exactly equivalent here
> since the index is newline-terminated records. Am I missing something?
No, you are not. I've read multiple times the code in unpack/unpack-src-l1
and see no reason why the generated index has no trailing new line; I mean,
sort adds it on its own even if missing!
$ echo -n foo | hd
00000000 66 6f 6f |foo|
00000003
$ echo -n foo | sort | hd
00000000 66 6f 6f 0a |foo.|
00000004
So, like I said: chomp workarounds the bug by simply not removing the
trailing character which in this case is *not* the, expected, line feed.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: