strange problem (bug?) with set_inline_types

From: <>
Date: Tue, 23 Nov 1999 14:35:55 +0100 (MET)
Message-Id: <>

I just found this strange behavior on the latest HM out from CVS. I don't know if it was there before.

When running hypermail on a file with a PDF and a .zip MIME attachments, the attachments are decoded and stored correctly in the attach dir. However, the links to these attachments were generated as if they were in-lined images, <IMG ..> rather than external ones <A HREF= ..>.

I traced the problem so far to the the prefered_types option in the .hmrc file.

In my .hmrc file I have this option:

prefered_types = text/plain text/html *

And no inline_types option (so I should use its default value).

When I have the ending "*" char, the set_inline_types variable takes the value of the set_prefered_types one. That's why I see the links to the attachments as <IMG>.

If I remove the ending "*" char, it works as expected. The set_inline_types takes its default value.

On the contrary, if I let my options with the ending "*" char and add a new one inline_types with the same value as the default one for this option, it doesn't work.

I think the problem may come from the initialization of the default values in setup.c:

	case CFG_LIST:
	    if (defval) {
                char *tpstr;
                tpstr = strsav(defval);
		*(struct hmlist **)cfg[i].value = NULL;
		*(struct hmlist **)cfg[i].value =
		    (void *)add_list((struct hmlist *)cfg[i].value, tpstr);
		*(struct hmlist **)cfg[i].value = NULL;


>From my debugging session, set_inline_types mysteriously has the same values
as set_prefered_types.

Both pointers are different:

(gdb) p set_prefered_types
$114 = (struct hmlist *) 0x4a638
(gdb) p set_inline_types
$115 = (struct hmlist *) 0x484b4

But both structures are linked ( == set_prefered_types).

(gdb) p *set_inline_types
$117 = {val = 0x484b4 "", next = 0x4a638} (gdb) p set_prefered_types
$113 = {val = 0x4b670 "image/gif", next = 0x4a648}

As both set_inline_types and set_prefered types are intialized to NULL, this lines looks suspicious:

    *(struct hmlist **)cfg[i].value = NULL;

As it looks like if we're trying to assing something to an unallocated memory zone.

I'll try changing it to:

        (struct hmlist **)cfg[i].value = NULL;

Is anyone more familiar with this code? Your expertise may save me debugging time :)

In all cases, it looks like a real bug.


-Jose Received on Tue 23 Nov 1999 03:37:29 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT