David Levine [Fri, 4 Jan 2013 03:59:44 +0000 (21:59 -0600)]
In cpstripped() and cptrimmed(), if a multibyte character is
found, only count it as taking up one character in the
destination buffer (if it has enought room). This way,
scan(1)'s output won't be jagged if there are any subjects,
for example, that have multibyte characters.
Added a test for this to test-scan-multibyte, and moved the
test for an invalid multibyte sequence from test-scan to it.
David Levine [Thu, 3 Jan 2013 02:07:43 +0000 (20:07 -0600)]
Fixed decoding of header fields when they contain a character that
can't be converted. Added test case to test-scan. valgrind also
noticed that things went amiss.
David Levine [Wed, 26 Dec 2012 15:52:12 +0000 (09:52 -0600)]
Restored an explicit refill of the buffer in m_getfld() that I
removed in the big stdio cleanup. Its need is shown by reducing
the message buffer size to 2048.
David Levine [Wed, 26 Dec 2012 01:25:43 +0000 (19:25 -0600)]
Removed call to fpurge() and its platform-specific emulations
from discard.c. discard() is called on stdout from mhl(1) and
msh(1) in interrupt handlers, and post(8) but only with -debug.
tcflush() should do the purge when stdout is a terminal. If
it's a file or pipe, well, maybe some garbage could get flushed
out. And it's called on the streams that post uses to talk to
its smtp server, so removed those calls because they no longer
do anything. And removed LINUX_STDIO define from configure.ac.
David Levine [Sat, 22 Dec 2012 17:51:21 +0000 (11:51 -0600)]
Changed bufsz argument of m_getfld() to be in-out instead of in.
This allowed removal of the msg_count global, in turn allowing
removal of sbr/m_msgdef.c
Paul Fox [Thu, 29 Nov 2012 18:59:55 +0000 (13:59 -0500)]
show: remove unreachable code
the stanza in question has been impossible to reach for some time. i
believe its purpose was to give a non-mh display proc full pathname
arguments to work with. since we've chdir'd to the folder, giving it
message numbers (i.e., relative pathnames) is fine.
Paul Fox [Tue, 27 Nov 2012 02:00:28 +0000 (21:00 -0500)]
Artificial argv limits.
when i skimmed the code earlier, i was looking at all the uses of
MAXARGS -- many of which are used to size local arrays. converting
them all to be dynamically-sized might be a fair amount of work.
but looking at rmm.c, refile.c, and folder_delmsgs(), i don't think
that issue applies. the patch below fixes the problem, and makes
rmmproc and refile do the right thing (well, at least, the modern
thing). NB: i didn't test to the limit where execvp should return
E2BIG.
as for the rest of mh -- it's certainly possible to hit the MAXARGS
limit with other commands (show, for instance), but i suspect the
frequency is much lower, and those, too, can be fixed as needed.
paul
>From 9636bc0e1697829966f51d2c301cd5d730c38c0a Mon Sep 17 00:00:00 2001
From: Paul Fox <pgf@foxharp.boston.ma.us>
Date: Mon, 26 Nov 2012 20:49:55 -0500
Subject: [PATCH] rmm/refile: remove the MAXARGS limit when running rmmproc
David Levine [Fri, 23 Nov 2012 15:26:21 +0000 (09:26 -0600)]
slocal used to support two different formats for three of
its arguments:
[address info sender]
[-addr address] [-info data] [-sender sender]
But it hasn't properly supported the first form since at
least April 1999. So, I removed that first form from the
man page and the broken support from the code. Score
another for the test suite!
Ken Hornstein [Thu, 15 Nov 2012 19:21:20 +0000 (14:21 -0500)]
Fix a few bugs:
Make sure to add a ref when adding to the hash table.
Forgot the increment the format array inside of fmt_free().
Marked an allocated string when doing FT_LIT.
David Levine [Wed, 14 Nov 2012 14:47:14 +0000 (08:47 -0600)]
Removed support for zip from sendfiles. I added it as part of the
sendfiles rewrite, f8baa5a34335fc0fc8ccabfabc601d0af73ab769, a few
weeks ago. But because sendfiles fed zip from standard input, zip
would use Zip64 extensions. That would require unzip 6.0 or later
to extract, according to the zip man page. But current MacOS X
uses unzip 5.52, so it broke there.