segfault on rfc2047-like subject

[David Relson]

On Sat, 09 Oct 2004 01:04:45 +0200
Matthias Andree wrote:

> David Relson <relson at osagesoftware.com> writes:
> 
> > Here's the deal on the final NUL, i.e. the intent behind it.  Use of
> > word_t is supposed to use word.leng and not look beyond that number
> > of characters.  Having an extra byte (with value NUL) is a debugging
> > convenience.  It allows looking at the word.text as a "char *" (in
> > gdb).
> >
> > All allocations of word_t are supposed to use macro "D" (as in
> > "len+D") to allocate the extra byte and use macro "Z" (as in
> > "Z(word.leng)") to clear that byte.  With "#define DEBUG" enabled,
> > the macros work with the extra byte.  With "#define DEBUG" disabled,
> > the macros are no-ops (not allocating space or zeroing bytes).
> 
> I'm aware of all this, but the alleged debugging convenience defeats
> the purpose. If I need to look at intermediate values (i. e. how the
> NUL byte gets into the source stuff), I need to manually do something
> like:
> 
> print w->leng
> (note result, say 23)
> print *w->text at 23
> 
> I don't mind too much but I'm discarding assignments where I deem them
> unsafe.

Please don't remove all the D and Z macro uses.  I find them valuable.

I've started looking at text_decode.   So far, I see that the line
causing the segfault should use the Z.  However variable "len" has a bad
value, which is part of the problem.  I'm investigating and will have a
fix soon (with luck).