David Champion [Tue, 16 Oct 2012 23:13:13 +0000 (18:13 -0500)]
Add compiler and configure info to mutt -v output (closes #3537)
Makefile(.am) updated to produce conststrings.c, which contains
C strings representing:
* the compiler's own version information;
* the CFLAGS value from the Make environment
* the ./configure options
main.c is updated to print them when running 'mutt -v'.
txt2c.sh is added to produce conststrings.c. txt2c.sh uses a compiled
txt2c binary if possible, for complete fidelity to the source strings
in whatever encoding they may use. If txt2c is not available (could
not be compiled, or was not compiled natively) it falls back on a shell
function to approximate the output using sed and tr.
Currently, no callers were providing a non-NULL buffer to
mutt_buffer_init, and splitting it will allow more sane semantics for
buffer allocation, initialization, and destruction in a later patch.
It will cause mutt_buffer_* to segfault if it needs to grow the space.
Thanks to Steve Losh for discovering the issue. I have done some simple
grepping to find other cases, but some may remain.
gnutls:tls_compare_certificates: check strstr for failure (closes #3547)
A malformed certificate file could cause strstr to return an unhandled NULL.
Thanks to hhorak for the proposed patch. This one is similar but avoids using
memmem for the first time (I am not sure about its portability).
Dan Fandrich [Sat, 3 Dec 2011 19:13:10 +0000 (11:13 -0800)]
Declare many structures const (closes #3552)
Many structs used in mutt are actually constant but are defined
without the 'const' keyword. This can slow initialization (slightly)
in some environments due to extra copying and increases the amount of
writable RAM required at run-time, which can be significant on non-MMU
systems. Using const can also increase the opportunities for compiler
optimization.
The attached patch marks many such structures as const. On my test x86
build, this reduces the size of .data by over 50%.
David Champion [Wed, 13 Jul 2011 16:05:37 +0000 (11:05 -0500)]
Invalidate header caches when spam rules change. closes #3473
User 'exg' on #mutt reported a problem when using header cache with IMAP
and spam rules. Spam tags are retrieved from cache and not updated when
spam rules change.
1. Enable header caching in muttrc
2. Set spam rules in muttrc
3. Use IMAP (or POP or Maildir). Your spam rules store spam tags into
your message headers, and these get cached.
4. Quit mutt
5. Change your spam rules in muttrc
6. Relaunch mutt
7. Because of header caching, the rfc822 headers are not reparsed, and
spam rules are not reapplied. User has outdated spam tags.
Spam rules are applied during rfc822 header parsing because it's the
only time we get a full and unadulterated view of all headers. Once
header parse is done we have only processed headers and 'user headers'
(X-headers). We might do spam rule matching against the struct HEADER
copy of headers, except that:
a. the header might not be in HEADER if it's non-standard and not an
X-header;
b. spam rules are regular expressions matching any arbitrary header
line, and we would need to map these regexps to the header used to
create the HEADER fields. This would change the syntax and behavior
of spam rules dramatically.
One solution, perhaps stopgap, is to invalidate the header cache when
spam rules change. That's what this patch does. It alters the hcache
versioning algorithm so that in addition to using the compiled-in
checksum of mutt's structures definitions, we also mix in the user's
runtime spam rules. Any time spam rules change the hcachever hash value
changes, causing the hcache to be rewritten.
version.sh: fix(?) failure due to bizarre sh quoting rules
I have not checked POSIX, and sh quoting always makes my head hurt, but this
seems to suffice for my sh (actually bash in sh mode) when HGROOT contains a space.
Olaf Hering [Mon, 23 May 2011 10:59:14 +0000 (12:59 +0200)]
fix gcc 4.6 warning -Wunused-but-set-variable in pgppubring.c
pgppubring.c: In function 'pgp_parse_pgp3_sig':
pgppubring.c:424:17: warning: variable 'hashalg' set but not used [-Wunused-but-set-variable]
pgppubring.c:423:17: warning: variable 'pkalg' set but not used [-Wunused-but-set-variable]
Olaf Hering [Mon, 23 May 2011 10:59:12 +0000 (12:59 +0200)]
fix gcc 4.6 warning -Wunused-but-set-variable in crypt-gpgme.c
crypt-gpgme.c: In function 'show_one_sig_status':
crypt-gpgme.c:1311:21: warning: variable 'uid' set but not used [-Wunused-but-set-variable]
crypt-gpgme.c: In function 'pgp_gpgme_application_handler':
crypt-gpgme.c:2285:27: warning: variable 'anywarn' set but not used [-Wunused-but-set-variable]
crypt-gpgme.c:2159:8: warning: variable 'start_pos' set but not used [-Wunused-but-set-variable]
crypt-gpgme.c: In function 'crypt_getkeybystr':
crypt-gpgme.c:4094:7: warning: variable 'match' set but not used [-Wunused-but-set-variable]
Olaf Hering [Mon, 23 May 2011 10:59:11 +0000 (12:59 +0200)]
fix gcc 4.6 warning -Wunused-but-set-variable in imap.c
imap.c: In function 'imap_open_mailbox':
imap.c:558:15: warning: variable 'conn' set but not used [-Wunused-but-set-variable]
imap.c: In function 'imap_open_mailbox_append':
imap.c:777:15: warning: variable 'conn' set but not used [-Wunused-but-set-variable]
imap.c: In function 'imap_subscribe':
imap.c:1816:15: warning: variable 'conn' set but not used [-Wunused-but-set-variable]
imap.c: In function 'imap_complete':
imap.c:1944:15: warning: variable 'conn' set but not used [-Wunused-but-set-variable]
David Champion [Mon, 7 Mar 2011 16:17:59 +0000 (10:17 -0600)]
Extra information in mutt version string, redux.
Restores [f1b4d1d17200] functionality with a slight change to keep
'make dist' working (see backout in [6b38124a5b81]).
Automake is too much voodoo for me at this time, so I let it keep
VERSION. mutt.h defined MUTT_VERSION as VERSION and the code used that,
so I removed MUTT_VERSION from mutt.h and put it into config.h via
configure.ac. A couple of tweaks were needed elsewhere. This restores
the fancy-versioning feature within mutt and keeps 'make dist' happy.
I have applied 26 changesets applied since 1.5.21 was tagged, 22 of
which are in my mq patch series. A 1.5.21 release build that is not
mercurial-based would still appear simply as "1.5.21".
Michael Elkins [Sat, 11 Sep 2010 14:34:26 +0000 (07:34 -0700)]
Allow setting message security in send2-hook
This patch delays checking the message security options until after the user has an initial chance to edit the message. This allows the security options to be set in a send2-hook when using $edit_headers. Without this patch, the user has no way of automatically setting security based on recipients since the to/cc prompts are bypassed.
The other change in behavior is if the user happened to use a send2-hook to see if the message had security applied *prior* to editing the message, that no longer works.
projects / mutt / log