I've attached the patch with correct formatting because my email client 
replaces tabs with spaces. I'll leave the changelog entries as you 
suggested.

Thanks again,
Matthew

> Just make sure to put each change in the relevant ChangeLog, the one 
> "closest" to the change in the directory structure.  For example, for 
> you change, I would do:
>
> gdb/ChangeLog:
>
>     * python/py-value.c (convert_value_from_python): Consider terminating
>     NULL byte in string length.
>
> gdb/doc/ChangeLog:
>
>     * gdb.texinfo (Convenience Variables for Tracepoints): Mention that
>     trace_func should not be used with output and not printf.
>
> gdb/testsuite/ChangeLog:
>
>     * gdb.python/py-as-string.c (malloc): New function.
>     * gdb.python/py-as-string.exp (test_as_string): Test $_as_string on
>     a string with printf.
>     * gdb.python/py-mi.exp: Adjust array length.
>
>>> IIUC, the goal of overriding malloc is to ensure that the memory 
>>> return by malloc is not all zeroes, which would potentially hide the 
>>> bug?  If that's right, you could instead write a wrapper for malloc 
>>> instead of a replacement.  The wrapper would memset the allocated 
>>> buffer to 'x'es, for example.  This way, it will be safer in case 
>>> there are many calls to malloc or calls with size > 51.
>>>
>>> See option #2 of this answer: http://stackoverflow.com/a/262481
>>
>> Yes, that was the reason. I used this way because I read that gdb also
>> worked on non-POSIX systems (windows especially) and thought having a
>> working test on all systems would be preferred (though I didn't check
>> that all systems support the testing framework).
>> I believe that no other calls to malloc are made in the inferior for
>> this test, and that this program isn't used anywhere else, so this
>> limit of 51 bytes is never hit.
>> I agree this is a bug waiting to happen, so I can accept if the
>> alternate would be preferred, but I thought I'd mention my reasoning.
>
> That's a good justification too, I'm ok with either.
>
>