Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere

[resend without html bits added by "gmail offline"]

So, it seems that of all of Google's email clients, only full desktop
gmail allows you to send plain text email (if you're careful to make
sure "Rich formatting" has not been clicked).  The new offline gmail
sends html, gmail android app sends html, gmail mobile web sends html.
 Google's war on plain text continues...

Or have I overlooked the switch that makes gmail send plain text and
only plain text?

On Wed, Oct 5, 2011 at 7:53 PM, Brandon Casey [off-list ref] wrote:

On Thursday, September 15, 2011, Brandon Casey wrote:

quoted

On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt [off-list ref]
wrote:

quoted

Am 9/15/2011 3:59, schrieb Brandon Casey:

quoted

The "x"-prefixed versions of strdup, malloc, etc. will check whether
the
allocation was successful and terminate the process otherwise.

A few uses of malloc were left alone since they already implemented a
graceful path of failure or were in a quasi external library like
xdiff.

Signed-off-by: Brandon Casey <redacted>
---
 ...
 compat/mingw.c        |    2 +-
 compat/qsort.c        |    2 +-
 compat/win32/syslog.c |    2 +-

There is a danger that the high-level die() routine (which is used by
the
x-wrappers) uses one of the low-level compat/ routines. IOW, in the case
of errors, recursion might occur. Therefore, I would prefer that the
compat/ routines do their own error reporting (preferably via return
values and errno).

Thanks.  Will do.

Hi Johannes,
I have taken a closer look at the possibility of recursion with respect to
die() and the functions in compat/.  It appears the risk is only related to
vsnprintf/snprintf at the moment.  So as long as we avoid calling xmalloc et
al from within snprintf.c, I think we should be safe from recursion.
I'm inclined to keep the additions to mingw.c and win32/syslog.c since they
both already use the x-wrappers or strbuf, even though they could easily be
worked around.  The other file that was touched is compat/qsort, which
returns void and doesn't have a good alternative error handling path.  So,
I'm inclined to keep that one too.
Sound reasonable?
-Brandon