headers
vincent | 2 May 12:20
Gravatar

mutt/2218: Corrupted display in gnome-terminal

>Number:         2218
>Notify-List:    
>Category:       mutt
>Synopsis:       Corrupted display in gnome-terminal
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 02 12:20:55 +0200 2006
>Originator:     Vincent Lefevre
>Release:        cvs + patches
>Organization:
>Environment:
Linux/x86, using ncurses 5.5
>Description:
With the attached mbox file (1 message), the index is not correctly displayed in gnome-terminal (UTF-8):
the second 'B' is below the 'e' instead of being below the 'v'. As a consequence, there an additional 'E' on
the following line in the index (with a 80-column terminal).

This also leads to inconsistent display in complex cases (I couldn't reproduce this), where the cursor may
not be in front of the current message. For instance, when the user wants to delete a message, a wrong
message can be deleted.

Note: the "From:" header is invalid, but this comes from a spam, and Mutt shouldn't behave badly even in
these cases.
>How-To-Repeat:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rocco Rutte | 2 May 14:24
Picon

[PATCH] Fix memory function use

Hi,

the patch at:

   <http://user.cs.tu-berlin.de/~pdmef/mutt/patches/pdmef+fix+mem.diff>

fixes the use of mutt's memory function wrappers, namely safe_free().

First, it replaces some calls by FREE() and adds some checks to 
check_sec.sh since the first chunk in the diff for muttlib.c looks like 
it fixes a bug. Thus, the checks can make sense, IMHO. This also may be 
useful for people (like me) who run mutt with patches to check the 
patches used and notify the authors.

Note that I only added the checks to check_sec.sh, I didn't add the 
required comments to the sources affected to make it ignore the 
warnings. One of the committers should that (but I can do it, too).

   bye, Rocco
--

-- 
:wq!
Permalink | Reply | 12 comments |
headers
rado | 2 May 15:48
Picon
Favicon

mutt/2219: extend mailing-list recognition to Resent:- headers

>Number:         2219
>Notify-List:    
>Category:       mutt
>Synopsis:       extend mailing-list recognition to Resent:- headers
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue May 02 15:48:51 +0200 2006
>Originator:     Rado Smiljanic
>Release:        1.5.6 (confirmed by CVS user)
>Organization:
>Environment:
>Description:
When eMails get "bounce"d to mailing-lists, mailing-list checks fail when they are limited to regular
headers but ignore "Resent-" headers.
>How-To-Repeat:
>Fix:
extend checks to "Resent-" headers
>Add-To-Audit-Trail:

>Unformatted:
Permalink | Reply | 0 comments |
headers
Brendan Cully | 2 May 22:25
Gravatar

Re: [PATCH] Fix memory function use

On Tuesday, 02 May 2006 at 12:24, Rocco Rutte wrote:
> Hi,
> 
> the patch at:
> 
>   <http://user.cs.tu-berlin.de/~pdmef/mutt/patches/pdmef+fix+mem.diff>
> 
> fixes the use of mutt's memory function wrappers, namely safe_free().
> 
> First, it replaces some calls by FREE() and adds some checks to 
> check_sec.sh since the first chunk in the diff for muttlib.c looks like 
> it fixes a bug. Thus, the checks can make sense, IMHO. This also may be 
> useful for people (like me) who run mutt with patches to check the 
> patches used and notify the authors.
> 
> Note that I only added the checks to check_sec.sh, I didn't add the 
> required comments to the sources affected to make it ignore the 
> warnings. One of the committers should that (but I can do it, too).

I never got the point of FREE vs safe_free - I don't see it as a bug
to use safe_free, though it is an inconsistency. (In fact I generally
prefer inline functions to macros.) So I'd rather not get spammed by
check_sec warnings. This patch would be nicer if it either:
a) didn't have the check_sec hunk, or
b) updated all the safe_frees in vanilla mutt to use FREE (does this
   patch do this? I haven't actually tried applying it)

I don't see a good reason to deliberately use safe_free instead of
FREE at the moment (or vv). Is there one? If not, the
SAFE_FREE_CHECKED bit is probably unnecessary...
(Continue reading)

Permalink | Reply | 11 comments |
headers
Thomas Roessler | 2 May 22:36

Re: [PATCH] Fix memory function use

On 2006-05-02 13:25:30 -0700, Brendan Cully wrote:

> I don't see a good reason to deliberately use safe_free
> instead of FREE at the moment (or vv). Is there one?

One reason is that FREE just behaves like free, in that you
don't need to put in the & operator.  But that's about it.

I don't feel particularly strongly either way, but do think the
code should be consistent.

--

-- 
Thomas Roessler ยท Personal soap box at <http://log.does-not-exist.org/>.
Permalink | Reply | 2 comments |
headers
Rocco Rutte | 2 May 22:43
Picon

Re: [PATCH] Fix memory function use

Hi,

* Brendan Cully [06-05-02 13:25:30 -0700] wrote:

>I never got the point of FREE vs safe_free - I don't see it as a bug
>to use safe_free, though it is an inconsistency.

If I recall correctly, some years ago there was:

   safe_free (void**);
   #define FREE(X)       safe_free((void**)(X))

just to avoid having to write all the casts manually.

Now it's even more dangerous since safe_free() dereferences its 
pointers without a big fat warning somewhere. In fact, before adding the 
check_sec.sh checks I though about just adding a note somewhere but 
couldn't really find an accurate place for it...

Now for "core" mutt this isn't interesting IMHO, just for people who 
write patches.

I've removed the PATCHES/check_sec.sh changes and saved it as 'p1' in 
that directory which only replaces safe_free() by FREE().

Personally, I'd rather take to the time to double-check the use and keep 
the check_sec.sh part since the first chunk in muttlib.c really looks 
like a bug which could have been found that way. (and check_sec.sh would 
only complain if there's no ampersand before the operator to FREE() so 
not all FREE() calls are affected)
(Continue reading)

Permalink | Reply | 7 comments |
headers
allen | 2 May 23:47
Picon

mutt/2220: mutt does not parse wrapped From\ line

>Number:         2220
>Notify-List:    allen <at> cts.wustl.edu
>Category:       mutt
>Synopsis:       mutt does not parse wrapped From\  line
>Confidential:   no
>Severity:       normal
>Priority:       medium
>Responsible:    mutt-dev
>State:          open
>Keywords:       
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 02 23:47:12 +0200 2006
>Originator:     Allen Rueter
>Release:        Mutt 1.4.2.1i
>Organization:
Washington University
>Environment:
Linux 2.4.21-4.ELsmp (i686)
perl 5.8.5
procmail v3.22
>Description:
When filtering email headers thru a perl script via procmail,
the ^From yada-somehting-really-long <at> evenlonger.com Mon May  1 09:35:45 2006 got wrapped putting 2006
on the next line.

Mutt can't see the message in the inbox.
I see in rfc 822 say mail headers over 65 to 72 in length
should be wrapped. Is ^From\  exculded?
>How-To-Repeat:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brendan Cully | 2 May 23:59
Gravatar

Re: imap/2090: imap_delim_chars is not used consequently

Synopsis: imap_delim_chars is not used consequently

State-Changed-From-To: open->chatting
State-Changed-By: brendan
State-Changed-When: Tue, 02 May 2006 23:59:17 +0200
State-Changed-Why:
Thanks for the patch. $imap_delim_chars is probably broken, but it may be 
broken by design. I'm not sure it's necessarily a good idea to use characters 
other than the actual mailbox delimiter. Arguments for and against welcome.

**** Comment added by brendan on Tue, 02 May 2006 23:59:17 +0200 ****
Permalink | Reply | 0 comments |
headers
Brendan Cully | 3 May 00:08
Gravatar

Re: [PATCH] Fix memory function use

On Tuesday, 02 May 2006 at 20:43, Rocco Rutte wrote:
> Hi,
> 
> * Brendan Cully [06-05-02 13:25:30 -0700] wrote:
> 
> >I never got the point of FREE vs safe_free - I don't see it as a bug
> >to use safe_free, though it is an inconsistency.
> 
> If I recall correctly, some years ago there was:
> 
>   safe_free (void**);
>   #define FREE(X)       safe_free((void**)(X))
> 
> just to avoid having to write all the casts manually.
> 
> Now it's even more dangerous since safe_free() dereferences its 
> pointers without a big fat warning somewhere. In fact, before adding the 
> check_sec.sh checks I though about just adding a note somewhere but 
> couldn't really find an accurate place for it...

That's why I don't like the automatic cast - the compiler should get a
chance to check whether the argument is a ** type. That may be why the
current macro is
# define FREE(x) safe_free(x)

But I don't think I understand why safe_free is
void safe_free (void *)
instead of
void safe_free (void **)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Brendan Cully | 3 May 00:32
Gravatar

Re: [PATCH] Fix memory function use

On Tuesday, 02 May 2006 at 15:08, Brendan Cully wrote:
> On Tuesday, 02 May 2006 at 20:43, Rocco Rutte wrote:
> > Hi,
> > 
> > * Brendan Cully [06-05-02 13:25:30 -0700] wrote:
> > 
> > >I never got the point of FREE vs safe_free - I don't see it as a bug
> > >to use safe_free, though it is an inconsistency.
> > 
> > If I recall correctly, some years ago there was:
> > 
> >   safe_free (void**);
> >   #define FREE(X)       safe_free((void**)(X))
> > 
> > just to avoid having to write all the casts manually.
> > 
> > Now it's even more dangerous since safe_free() dereferences its 
> > pointers without a big fat warning somewhere. In fact, before adding the 
> > check_sec.sh checks I though about just adding a note somewhere but 
> > couldn't really find an accurate place for it...
> 
> That's why I don't like the automatic cast - the compiler should get a
> chance to check whether the argument is a ** type. That may be why the
> current macro is
> # define FREE(x) safe_free(x)
> 
> But I don't think I understand why safe_free is
> void safe_free (void *)
> instead of
> void safe_free (void **)
(Continue reading)

Permalink | Reply | 5 comments |

Gmane