[PATCH] sprinters: bugfix when NULL passed for a string.

[Mark Walters]

On Wed, 08 Aug 2012, Austin Clements <amdragon at MIT.EDU> wrote:
> LGTM.
>
> This won't commute with [0], since that introduces broken tests that are
> fixed by this patch.

Yes: I guess the tidiest might be for me to send a version of my patch
which marks these tests fixed so it can be applied after this.

> I think we should remove the fields in the JSON header object for
> missing headers (except perhaps From and Date, if those really are
> mandatory headers), but I think we should do that after the freeze,
> since it might affect frontends.  

I agree with you and Jamie on this. I think it is a `feature' rather
than a bugfix (the current patch just restores the output to what it was
before the sprinter changes it) so agree it should be after the
freeze. We could deprecate passing NULL to sprinter string functions
(possibly keep the check but fprintf a warning?)

For the From/Date headers see http://www.ietf.org/rfc/rfc2822.txt
section 3.6 for details:

   The only required header fields are the origination date field and
   the originator address field(s).  All other header fields are
   syntactically optional.

and origination date field means a Date: header, and originator
address field means a From: header. However, I don't think an empty
string is valid for either of these so we can't sensibly output
something standards compliant. Thus I would go for following the
original message and omit any fields not present in it.

> It probably makes sense to add an Emacs test or two to the tests in [0].

This seems like a good idea.

Best wishes

Mark


> [0] id:"1344389313-7886-1-git-send-email-amdragon at mit.edu"
>
> On Tue, 07 Aug 2012, Mark Walters <markwalters1009 at gmail.com> wrote:
>> The string function in a sprinter may be called with a NULL string
>> pointer (eg if a header is absent). This causes a segfault. We fix
>> this by checking for a null pointer in the string functions and update
>> the sprinter documentation.
>>
>> At the moment some output when format=text is done directly rather than
>> via an sprinter: in that case a null pointer is passed to printf or
>> similar and a "(null)" appears in the output. That behaviour is not
>> changed in this patch.
>> ---
>>
>> This could really do with some tests (it is the second time this type of
>> bug has occurred). To be considered as a message by notmuch new a file
>> needs at least one of a From: Subject: or To: header. Thus we should
>> have three messages each of which just contains that single header (and
>> nothing else) and check that search and show work as expected. 
>>
>>
>>
>>  sprinter-json.c |    2 ++
>>  sprinter-text.c |    2 ++
>>  sprinter.h      |    4 +++-
>>  3 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/sprinter-json.c b/sprinter-json.c
>> index c9b6835..0a07790 100644
>> --- a/sprinter-json.c
>> +++ b/sprinter-json.c
>> @@ -118,6 +118,8 @@ json_string_len (struct sprinter *sp, const char *val, size_t len)
>>  static void
>>  json_string (struct sprinter *sp, const char *val)
>>  {
>> +    if (val == NULL)
>> +	val = "";
>>      json_string_len (sp, val, strlen (val));
>>  }
>>  
>> diff --git a/sprinter-text.c b/sprinter-text.c
>> index dfa54b5..10343be 100644
>> --- a/sprinter-text.c
>> +++ b/sprinter-text.c
>> @@ -38,6 +38,8 @@ text_string_len (struct sprinter *sp, const char *val, size_t len)
>>  static void
>>  text_string (struct sprinter *sp, const char *val)
>>  {
>> +    if (val == NULL)
>> +	val = "";
>>      text_string_len (sp, val, strlen (val));
>>  }
>>  
>> diff --git a/sprinter.h b/sprinter.h
>> index 5f43175..912a526 100644
>> --- a/sprinter.h
>> +++ b/sprinter.h
>> @@ -27,7 +27,9 @@ typedef struct sprinter {
>>       * a list or map, followed or preceded by separators).  For string
>>       * and string_len, the char * must be UTF-8 encoded.  string_len
>>       * allows non-terminated strings and strings with embedded NULs
>> -     * (though the handling of the latter is format-dependent).
>> +     * (though the handling of the latter is format-dependent). For
>> +     * string (but not string_len) the string pointer passed may be
>> +     * NULL.
>>       */
>>      void (*string) (struct sprinter *, const char *);
>>      void (*string_len) (struct sprinter *, const char *, size_t);
>> -- 
>> 1.7.9.1
>>
>>
>> H
>> _______________________________________________
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch