- s-nail-14_5_2-mimeheader.patch
<http://downloads.sourceforge.net/project/s-nail/s-nail-14_5_2-mimeheader.patch>
Subject: ehm, .getElementById("blink") needs <span
=?US-ASCII?Q?id=3D"blink">,?= not =?US-ASCII?Q?class=3D"id"?=
Such a header would yet be displayed without the " not " in
between the two encoded words because of faulty
"encoded-word-continuation" detection (note the quotation
marks). The error path could also have been seen in mail
forwarding and in faulty searching etc.
This patch is in a row of fixes for my hasty [0f9ad93] from
2013-03-12 that already caused the v14.2 minor release (because
of [b608c6b] from 2013-03-14). Those with mercy may read the
commit message of [c81afce].
This is a really critical fix, and for a moment i thought about
releasing a subminor immediately, but because my massive
N(ot)-Y(et)-D(ead) rewrite, which already revealed, well, this and
that, is not yet completed (not to talk about reviewing that one),
i did not, i.e., just in case i find more bugs.
I want to emphasize on the last sentence -- *unfortunately* S-nail
will until at least v15 continue to display a subject like
Subject: are
you
unperfect
on three successive lines instead of joining it. Of course this
was already the case before this bugfix. :-))
..because i didn't sent the former [BUGFIX] to my `nail-announce'
alias but only to `nail' i also append the bugfix from 2014-01-30:
- s-nail-14_5_2-sort.patch
<http://downloads.sourceforge.net/project/s-nail/s-nail-14_5_2-sort.patch>
Reverses (sort(),thread(): use srelax()!, 2014-01-18, [a9b67e9]),
which was a hasty commit of an untested diff that i've added few
minutes beforehand:
As a rather careless last-minute change i've added string relaxation
to threaded and sorted display, but it's really one more step towards
lowering memory pressure -- i couldn't resist [a9b67e9] after seeing
An alternative, forward-heading patch that keeps string relaxation has
been pushed to [master] as [5e75529] and is also available as
s-nail-14_5_2-sort-alt.patch.
I highly recommend git(1) users to update their [master] branch.
Look out, you Rock'n Rollers...
--steffen
s-nail-14_5_2-mimeheader.patch, 2014-02-05:
Apply:
$ cd s-nail-14.5.2
$ patch -bu < s-nail-14_5_2-mimeheader.patch
Description:
mime_fromhdr(): fix my rewrite again..
My hasty rewrite [0f9ad93] (mime_fromhdr(): partial rewrite using
n_iconv_str(), 2013-03-12), just about ninety (90) minutes before
the release of S-nail v14.1 already caused the bugfix [b608c6b]
(mime_fromhdr(): never return NULL output.., 2013-03-14), which
was the sole reason for the release of S-nail v14.2.
Well, about a year later, after tens of thousands of mails,
including multibyte ones, i wrote myself a message that has shown
that the rewrite was still buggy -- the header
Subject: ehm, .getElementById("blink") needs <span
=?US-ASCII?Q?id=3D"blink">,?= not =?US-ASCII?Q?class=3D"id"?=
cannot be viewed correctly, the ", not" will be lost.
The reason is now understood and this changeset should fix
mime_fromhdr() so that it'll do what it is assumed to do in the
current codebase, unless i'm terribly mistaken.
Because i bickered some time in private, i WANT to add that the
real problem is that the codebase is weird INSOFAR as that i still
don't really understand the WAY it works, because THAT IS SICK.
I.e., in my brain i assume this function effectively is
rfc_2047_decode(), meant to decode encoded words as specified in
RFC 2047, but that's simply not true, and FOR QUITE SOME TIME,
because of the embedded newlines that may be in the data and need
to passed through for at least the case that we send data to the
display. I slowly get around that schizophrenic codebase while
also converting it to a straight one, but that will take years.
Until then we need to strip whitespace in between multiple
adjacent encoded words, while passing through newlines and
whitespace that follows newlines, regardless of whatever.
I hope this will do it until we are sane.
---
mime.c | 63 +++++++++++++++++++++++++++++++++++++++------------------------
1 file changed, 39 insertions(+), 24 deletions(-)
diff --git a/mime.c b/mime.c
index ccb0061..6ee55cc 100644
--- a/mime.c
+++ b/mime.c
@@ -863,20 +863,26 @@ jclear:
goto jleave;
}
-/*
- * Convert header fields from RFC 1522 format
- * TODO mime_fromhdr(): NO error handling, fat; REWRITE **ASAP**
- */
FL void
mime_fromhdr(struct str const *in, struct str *out, enum tdflags flags)
{
- /* TODO mime_fromhdr(): is called with strings that contain newlines;
- * TODO this is the usual newline problem all around the codebase;
- * TODO i.e., if we strip it, then the display misses it ;} */
+ /* TODO mime_fromhdr(): is called with strings that contain newlines;
+ * TODO this is the usual newline problem all around the codebase;
+ * TODO i.e., if we strip it, then the display misses it ;>
+ * TODO this is why it is so messy and why S-nail v14.2 plus additional
+ * TODO patch for v14.5.2 (and maybe even v14.5.3 subminor) occurred, and
+ * TODO why our display reflects what is contained in the message: the 1:1
+ * TODO relationship of message content and display!
+ * TODO instead a header line should be decoded to what it is (a single
+ * TODO line that is) and it should be objective to the backend wether
+ * TODO it'll be folded to fit onto the display or not, e.g., for search
+ * TODO purposes etc. then the only condition we have to honour in here
+ * TODO is that whitespace in between multiple adjacent MIME encoded words
+ * TODO รก la RFC 2047 is discarded; i.e.: this function should deal with
+ * TODO RFC 2047 and be renamed: mime_fromhdr() -> mime_rfc2047_decode() */
struct str cin, cout;
char *p, *op, *upper, *cs, *cbeg;
- int convert;
- size_t lastoutl = (size_t)-1;
+ ui32_t convert, lastenc, lastoutl;
#ifdef HAVE_ICONV
char const *tcs;
iconv_t fhicd = (iconv_t)-1;
@@ -894,6 +900,7 @@ mime_fromhdr(struct str const *in, struct str *out, enum tdflags flags)
#endif
p = in->s;
upper = p + in->l;
+ lastenc = lastoutl = 0;
while (p < upper) {
op = p;
@@ -949,8 +956,7 @@ mime_fromhdr(struct str const *in, struct str *out, enum tdflags flags)
--cout.l;
} else
(void)qp_decode(&cout, &cin, NULL);
- if (lastoutl != (size_t)-1)
- out->l = lastoutl;
+ out->l = lastenc;
#ifdef HAVE_ICONV
if ((flags & TD_ICONV) && fhicd != (iconv_t)-1) {
cin.s = NULL, cin.l = 0; /* XXX string pool ! */
@@ -966,21 +972,30 @@ mime_fromhdr(struct str const *in, struct str *out, enum tdflags flags)
#ifdef HAVE_ICONV
}
#endif
- lastoutl = out->l;
+ lastenc = lastoutl = out->l;
free(cout.s);
- } else {
-jnotmime:
- p = op;
- convert = 1;
- while ((op = p + convert) < upper &&
- (op[0] != '=' || op[1] != '?'))
- ++convert;
- out = n_str_add_buf(out, p, convert);
- p += convert;
- if (! blankchar(p[-1]))
- lastoutl = (size_t)-1;
- }
+ } else
+jnotmime: {
+ bool_t onlyws;
+
+ p = op;
+ onlyws = (lastenc > 0);
+ for (;;) {
+ if (++op == upper)
+ break;
+ if (op[0] == '=' && (PTRCMP(op + 1, ==, upper) || op[1] == '?'))
+ break;
+ if (onlyws && !blankchar(*op))
+ onlyws = FAL0;
+ }
+
+ out = n_str_add_buf(out, p, PTR2SIZE(op - p));
+ p = op;
+ if (!onlyws || lastoutl != lastenc)
+ lastenc = out->l;
+ lastoutl = out->l;
}
+ }
out->s[out->l] = '\0';
if (flags & TD_ISPR) {
s-nail-14_5_2-sort.patch, 2014-01-30:
Apply:
$ cd s-nail-14.5.2
$ patch -bu < s-nail-14_5_2-sort.patch
Description:
Reverses (sort(),thread(): use srelax()!, 2014-01-18, [a9b67e9]), which
was a hasty commit of an untested diff that i've added few minutes
beforehand.
It was of course wrong.
The problem (no memory relaxation during entire sort operation) requires
a different approach (either only relax when we don't need to hold
dope storage (as for SORT_TO/SORT_FROM/SORT_SUBJECT/+) or use heap
memory for those allocations, then).
s-nail-14_5_2-sort-alt.patch is an alternative working thesis that uses
heap allocations, thus continues to relax the dope storage.
This version has been pushed to [master].
diff --git a/thread.c b/thread.c
index 3ac5966..9ec1ac9 100644
--- a/thread.c
+++ b/thread.c
@@ -361,8 +361,6 @@ makethreads(struct message *m, long cnt, int nmail)
return;
mprime = nextprime(cnt);
mt = scalloc(mprime, sizeof *mt);
-
- srelax_hold();
for (i = 0; i < cnt; i++) {
if ((m[i].m_flag&MHIDDEN) == 0) {
mlook(NULL, mt, &m[i], mprime);
@@ -376,7 +374,6 @@ makethreads(struct message *m, long cnt, int nmail)
m[i].m_level = 0;
if (!nmail && !(inhook&2))
m[i].m_collapsed = 0;
- srelax();
}
/*
* Most folders contain the eldest messages first. Traversing
@@ -387,12 +384,8 @@ makethreads(struct message *m, long cnt, int nmail)
* are replies to the one message, and are sorted such that
* youngest messages occur first.
*/
- for (i = cnt-1; i >= 0; i--) {
+ for (i = cnt-1; i >= 0; i--)
lookup(&m[i], mt, mprime);
- srelax();
- }
- srelax_rele();
-
threadroot = interlink(m, cnt, nmail);
finalize(threadroot);
free(mt);
@@ -572,8 +565,6 @@ sort(void *vp)
default:
break;
}
-
- srelax_hold();
for (n = 0, i = 0; i < msgCount; i++) {
mp = &message[i];
if ((mp->m_flag&MHIDDEN) == 0) {
@@ -637,10 +628,7 @@ sort(void *vp)
mp->m_child = mp->m_younger = mp->m_elder = mp->m_parent = NULL;
mp->m_level = 0;
mp->m_collapsed = 0;
- srelax();
}
- srelax_rele();
-
if (n > 0) {
qsort(ms, n, sizeof *ms, func);
threadroot = &message[ms[0].ms_n];
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
S-nail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/s-nail-users
