NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/50827 (sh -c ': "${x=$((1))}"' gives bogus syntax error)



The following reply was made to PR bin/50827; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	rhansen%rhansen.org@localhost
Subject: Re: bin/50827 (sh -c ': "${x=$((1))}"' gives bogus syntax error)
Date: Sat, 20 Feb 2016 20:22:11 -0500

 On Feb 21,  8:19am, kre%munnari.OZ.AU@localhost (Robert Elz) wrote:
 -- Subject: Re: bin/50827 (sh -c ': "${x=$((1))}"' gives bogus syntax error)
 
 | Don't jump for joy just yet.  The two expressions in the PR both work
 | (produce the same, correct, result) but there is potential for much
 | other breakage I have not yet tested, plus more variants of the expr
 | in question tha also need to work, also yet untested.
 
 | So some progress, but too early to open the champaign...
 
 Ok, I will put it back in the fridge.
 
 | While here I'll ask another question ... the code in sh is sprinkled
 | with "volatile" all over the place (particularly in the area I have
 | been looking.)   I gather this is to appease gcc wrt setjmp/longmp
 | (the FreeBSD code has a comment - or maybe commit log entry - simply
 | refusing to go that route...)   Does anyone mind if I strip out most
 | of that, and add "just the right" volatile vars, so the trap longjmp
 | stuff works (at least in the token reading functions) - or should work,
 | modulo whatever nonsense gcc gets up to, and remove it from all the
 | rest?  (If I do that I'll make it a separate patch.)   All that (unnecessary)
 | volatile nonsense has to be slowing shell execution, and with my fixes,
 | it will be even worse.   Until I remove it so I can measure the effect, I
 | don't know how much difference it really makes, but ...   And of course,
 | nothing will happen there until the substantive changes are all fully
 | tested (and corrected if needed.)
 
 I think that most of the volatile was because gcc wanted it... I don't
 mind the cleanup, go for it. But expect transient breakage amongst different
 ports. Also our shell does vfork() which is a nother volatile creator, I
 don't think that FreeBSD supports that.
 
 christos
 


Home | Main Index | Thread Index | Old Index