Re: [PATCH 2/4] cleanup: use internal memory allocation wrapper functions everywhere
- From
Brandon Casey <drafnel@gmail.com>
- Date
- Oct 6, 2011, 02:00 UTC
- Message-ID
- <CA+sFfMdHpvdMU==a2sUR9sZZCcgqPfGF7+dy6yi8RVoMZ+uZVA@mail.gmail.com>
- In-Reply-To
- <CA+sFfMf73K3yv_5K633DKOsVufMV6rTjd+SSunq4sBikt4jCsg@mail.gmail.com>
[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 <drafnel@gmail.com> wrote:
Show 42 quoted lines
> On Thursday, September 15, 2011, Brandon Casey wrote: >> >> On Thu, Sep 15, 2011 at 1:52 AM, Johannes Sixt <j.sixt@viscovery.net> >> wrote: >> > Am 9/15/2011 3:59, schrieb Brandon Casey: >> >> 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 <drafnel@gmail.com> >> >> --- >> >> ... >> >> 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 >