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

[Rich Felker <dalias@libc.org>]

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.

Rich