Jonas Smedegaard <[EMAIL PROTECTED]> wrote:
> Could someone please check if the problem persist even with the newer
> release?
>
> And if the problem does persist, could someone post a test case that I
> can provide upstream?
Hi,
the problem is present in 1.0.3-2 too.
I'm attaching a test script that demonstrates the problem AIUI.
When run on a plain text file that contains a ':0:' in the
beginning of the line, it outputs an error:
% cat a
:0:
kalimantan% ./test-uu.pl a
a: 1 parts
Decoding part 0
decode: Invalid argument ('File I/O Error') at ./test-uu.pl line 16.
If the file does not match this, no encoded parts are found:
kalimantan% cat b
:0:
kalimantan% ./test-uu.pl b
b: 0 parts
Upstream 1.0.4 is an improvement: if survives the above, but fails if
there's the string "\n\n:0:" in the middle of the file, which is still
quite possible in the original scenario (mail including a procmail
recipe.)
I'm not very familiar with uulib, but I guess this bug could be
considered a feature. It looks to me like the decode() function returns
an error message where appropriate, so the question is how well the
scan in LoadFile() should recognize encoded contents. This is probably
a matter of taste. But that's for upstream to decide, of course.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
#!/usr/bin/perl -w
use strict;
use Convert::UUlib qw(:all);
for (@ARGV) {
my ($retval, $count) = LoadFile $_ ;
print "$_: $count parts\n";
}
for (my $i = 0; my $uu = GetFileListItem $i; $i++) {
print "Decoding part $i\n";
if ($uu->state & FILE_OK) {
my $sts = $uu->decode;
$sts & RET_OK or die("decode: $! ('" . strerror($sts). "')");
}
}
