[Mimedefang] $fname in filter() is an array reference

Matt Garretson mattg at assembly.state.ny.us
Mon Mar 1 18:05:38 EST 2010


I've noticed this for a while, but have only now gotten around to 
looking into it.  Maybe it doesn't matter, but I just figured I'd 
mention it.  This is MD version 2.68 on Fedora 12 (as well as
previous versions of both) ...

In mimedefang-filter, both filter() and filter_multipart() are 
passed a value ($fname in the example filter) that is supposed to 
be a string containing a suggested filename for the entity. 
However, what's really getting passed is an array reference. (If 
you print $fname, you'll get "ARRAY(0x3ee5968)" or some such.)

I think this is because of the way $fname is defined in
rebuild_entity() in mimedefang.pl :

    my($fname) = takeStabAtFilename($in);

My understanding is that the parens cause takeStabAtFilename() to 
be called in a list context, which in turn for is causing MIME-tools' 
decode_mimewords() to return an array rather than a scalar. The 
attached trivial patch to mimedefang.pl.in ditches the parens, 
causing $fname to be a scalar string as documented within MIMEdefang.

Now, the man page for MIME::Words says that forcing decode_mimewords()
to return a scalar is "probably not what you want", but it certainly
is easier to deal with, and it matches the MD's comments and docs.

I don't know what bad side effects my patch might cause, but 
hopefully those smarter than I here can shed some light on it.

Thanks!
-Matt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <https://lists.mimedefang.org/pipermail/mimedefang_lists.mimedefang.org/attachments/20100301/57fb8911/attachment.txt>


More information about the MIMEDefang mailing list