segfault on rfc2047-like subject

[Matthias Andree]

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.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)