Re: [PATCH] remove unused variables from dynlink.c

[Rich Felker <dalias@libc.org>]

On Sun, May 12, 2019 at 10:31:31AM -0400, Rich Felker wrote:
> On Sun, May 12, 2019 at 10:24:08PM +0800, Fangrui Song wrote:
> > On 2019-05-12, Rich Felker wrote:
> > >On Sun, May 12, 2019 at 09:51:07AM -0400, Rich Felker wrote:
> > >>On Sun, May 12, 2019 at 09:50:50AM +0800, Fangrui Song wrote:
> > >>>
> > >>> ---
> > >>> ldso/dynlink.c | 1 -
> > >>> 1 file changed, 1 deletion(-)
> > >>>
> > >>> diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> > >>> index 42a5470d..ad0cdba2 100644
> > >>> --- a/ldso/dynlink.c
> > >>> +++ b/ldso/dynlink.c
> > >>> @@ -86,7 +86,6 @@ struct dso {
> > >>> 	size_t relro_start, relro_end;
> > >>> 	uintptr_t *new_dtv;
> > >>> 	unsigned char *new_tls;
> > >>> -	volatile int new_dtv_idx, new_tls_idx;
> > >>> 	struct td_index *td_index;
> > >>> 	struct dso *fini_next;
> > >>> 	char *shortname;
> > >>> --
> > >>> 2.21.0
> > >>
> > >>Looks ok. Your mail client seems to have corrupted the patch though;
> > >>git am is rejecting it for some reason. I'll apply it manually. In the
> > >>future if you can't get your mail client to send patches inline
> > >>without breaking the formatting, attachments are fine/preferred.
> > >
> > >For future reference, I found what happened: it seems to have removed
> > >the leading space at the beginning of the context lines (lines with no
> > >+ or -).
> > >
> > >Rich
> > 
> > Weird. I created the patch with `git format-patch --stdout -1 HEAD`,
> > sent an email with neomutt to myself, then resent (<esc>e) it to the
> > musl mailing list. Just now I checked my copy of the sent mail has the
> > desired leading \t.
> 
> The \t is part of the content, but unified diff lines have a single
> character *before* the content that's either space (pure context) or +
> or - (line added or removed). Something in your mail processing seems
> to have stripped the space and left only the tab (presumably thinking
> space+tab is "the same as" just a tab... *sigh*)
> 
> Oddly, GNU patch accepts the version with the space stripped, but this
> can't be done in general; it would be ambiguous if there were also
> leading spaces in the content. git[-am/-apply] is a lot more strict
> about things like this.

OK, this was all my fault -- my mutt session had pipe_decode turned
on, and it did this mess. Normally I have it off but I'd turned it on
temporarily for something and forgotten about it. Sorry for the noise!

(This is perhaps another reason to prefer attachments, though?)

Rich