remove unused variables from dynlink.c

Submitted by Fangrui Song on May 12, 2019, 1:50 a.m.

Details

Message ID 20190512015050.wjm37cco537skyf5@gmail.com
State New
Series "remove unused variables from dynlink.c"
Headers show

Commit Message

Fangrui Song May 12, 2019, 1:50 a.m.
---
 ldso/dynlink.c | 1 -
 1 file changed, 1 deletion(-)

Patch hide | download patch | download mbox

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;

Comments

Rich Felker May 12, 2019, 1:51 p.m.
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.

Rich
Rich Felker May 12, 2019, 1:54 p.m.
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
Fangrui Song May 12, 2019, 2:24 p.m.
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.

I'll just attach a text/x-diff file next time.
Rich Felker May 12, 2019, 2:31 p.m.
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
Rich Felker May 12, 2019, 2:48 p.m.
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