Subject: Re: [PATCH 12/20] config: plug various memory leaks

From: Patrick Steinhardt <[email-masked]>
Date: Fri, 24 May 2024 08:58:21 +0200

On Thu, May 23, 2024 at 10:13:24AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> writes:
> > diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
> > index 75216f19ce..7120030b5c 100755
> > --- a/t/t4210-log-i18n.sh
> > +++ b/t/t4210-log-i18n.sh
> > @@ -1,6 +1,8 @@
> >  #!/bin/sh
> >  
> >  test_description='test log with i18n features'
> > +
> > +TEST_PASSES_SANITIZE_LEAK=true
> >  . ./lib-gettext.sh
> >  
> >  # two forms of é
> 
> You've been sending your patches as "multipart/signed" (which by the
> way was cumbersome enough for me but that is primarily the problem
> with Emacs/GNUS and we should handle multipart/signed well), whose
> header reads like so:
> 
> Content-Type: multipart/signed; micalg=pgp-sha512;
> 	protocol="application/pgp-signature"; boundary="ovDSRLSkA00eIgbN"

Well, signing is of dubious value anyway, but it does have the upside of
stressing our toolchain a bit more and thus making it (hopefully) more
robust :) If it bothers you, then I can probably stop doing so. But for
now I will keep it as-is.

> The "message" part in it says that it is encoded in iso-8859-1:
> 
>     --ovDSRLSkA00eIgbN
>     Content-Type: text/plain; charset=iso-8859-1
>     Content-Disposition: inline
>     Content-Transfer-Encoding: quoted-printable
> 
>     ...
>     diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
>     index 75216f19ce..7120030b5c 100755
>     --- a/t/t4210-log-i18n.sh
>     +++ b/t/t4210-log-i18n.sh
>     @@ -1,6 +1,8 @@
>      #!/bin/sh
>     =20
>      test_description=3D'test log with i18n features'
>     +
>     +TEST_PASSES_SANITIZE_LEAK=3Dtrue
>      . ./lib-gettext.sh
>     =20
>      # two forms of =E9
> 
> But the source in t/t4210-log-i18n.sh actually is written in UTF-8.
> The thing is, the "-u" option (recode into utf-8" is supposed to be
> the default for "git am", and it is passed down to the underlying
> mailinfo machinery in builtin/am.c:parse_mail().
> 
> But apparently that is not working correctly.  I see in the patch an
> unrecoded byte E9 in the resulting patch file that is fed to the
> underlying "git apply" machinery, failing the application.

Hm. I'll double check mail headers before sending out the next iteration.

Patrick