The sample program to demonstrate the bug at CPAN, has MMagic analyse a string containing the letter 'a' and this bug report has MMagic analysing the contents of the /etc/debian_version file.
At the point in checktype_contents() where it is about to call itself again (hence the infinite recursion problem), the suggestion is that checktype_container() be called instead. In order for checktype_container to be of any use here, the $self object needs to have something useful in the chook component of the object. At this point, chook is empty, which is going to result in checktype_container returning an empty string to checktype_contents. Debugging in emacs/perldb, I tried calling checktype_data instead, and it would end up returning undef in trying to identify data for a string of 'a'. I made the suggested change in sub checktype_contents(). The subroutine checktype_container() doesn't return a type. Checktype_magic() is called next, it too fails. Checktype_data() also can't find a type. Which would result at the end, of a type of text/plain be assigned for the type, if that line of code wasn't commented out. So it returns undef. Trying a string of "#!/usr/bin/perl\n", MMagic also returns undef. Trying a string of: '<html><head><title>Title</title></head><body><p>Body</p></body></html>' , MMagic returns text/html. To me, it sort of looks like this checktype_container() was added for some reason, but the changes were never completed. It kinds of looks like the user has to provide their own subroutines to check for the contents of containers (similar to checktype_*), but there doesn't seem to be documentatino on this. But I am just guessing. I never looked at this code before. Downloading the tarball from CPAN, the only function really tested is checktype_filename(), and the only types returned are text/plain and text/html in the tests. Gord -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
