On Sat, Oct 05, 2013 at 08:35:56PM -0400, Aaron Schrab wrote:
Here's a new version of that first patch adjusted to apply after the
other one.
Applied. http://dev.mutt.org/trac/changeset/6309
At 19:28 + 05 Oct 2013, Michael Elkins wrote:
On Thu, Aug 22, 2013 at 03:10:36PM -0400, Aaron Schrab wrote:
Indeed, I'd already completed the following patch before seeing this
message. It replaces use of memset with mutt_buffer_init. Even if
there's a later move to do more in another in
Michael Elkins wrote:
> Applied. http://dev.mutt.org/trac/changeset/6308
Just to make sure it doesn't slip through the cracks, this
was actually a two-part patch. Aaron's first patch in email
20130822190611.ga14...@pug.qqx.org added calls to mutt_buffer_init() for
some err variables in addition
On Thu, Aug 22, 2013 at 03:10:36PM -0400, Aaron Schrab wrote:
At 13:25 -0500 22 Aug 2013, Derek Martin wrote:
In any event, having found the mutt_buffer_* functions (in protos.h
and muttlib.c), I think the initializations should use those functions
instead of calling memset().
Indeed, I'd alr
Aaron Schrab wrote:
> Subject: [PATCH] Consistently use mutt_buffer_init function
>
> Despite the existence of the mutt_buffer_init function, most
> initializations were instead done with memset. Use the specific
> function instead to make it easier if later changes are made to how the
> initiali
Aaron Schrab wrote:
> --- 8< ---
>
> Subject: [PATCH] Initialize BUFFER variables
>
> Ensure that BUFFER variables are initialized to prevent later attempts
> to traverse an uninitialized pointer.
> ---
> commands.c |1 +
> hook.c |7 +--
> imap/command.c |1
On Thu, Aug 22, 2013 at 03:34:33PM -0500, Derek Martin wrote:
> You could go crazy, and have all of these (with whatever names):
Or you could pick one and always use it... Makes the patch more work
tho.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This mes
On Thu, Aug 22, 2013 at 03:06:11PM -0400, Aaron Schrab wrote:
> There are a number of places where the data for the buffer is
> allocated in a different place than the buffer itself, or where the
> buffer data is a stack variable. That type of API wouldn't work in
> those cases.
Indeed... this is
At 13:25 -0500 22 Aug 2013, Derek Martin wrote:
In any event, having found the mutt_buffer_* functions (in protos.h
and muttlib.c), I think the initializations should use those functions
instead of calling memset().
Indeed, I'd already completed the following patch before seeing this
message.
At 10:51 -0500 22 Aug 2013, Derek Martin wrote:
Given this code and the fix, it seems likely that the problem you ran
into is that err.dptr is used uninitialized. Since err is half
initialized in the code that follows, I personally think it would be
slightly preferable to add:
err.dptr = NUL
On Thu, Aug 22, 2013 at 10:51:12AM -0500, Derek Martin wrote:
> THAT said, I'm betting there are other places in the code where there
> are BUFFER structs which aren't initialized properly. Might be worth
> creating a function/macro to initialize these things properly... e.g.:
In fact, such funct
On Wed, Aug 21, 2013 at 05:49:24PM -0400, Aaron Schrab wrote:
> Clear newly allocated error buffer to avoid attempt to dereference an
> invalid pointer when reporting an error while sourcing a file. Without
> this change I was seeing segfaults when attempting to source a file
> containing a send2-
Clear newly allocated error buffer to avoid attempt to dereference an
invalid pointer when reporting an error while sourcing a file. Without
this change I was seeing segfaults when attempting to source a file
containing a send2-hook with an invalid regexp in the pattern.
---
commands.c |1 +
1
13 matches
Mail list logo
