Linux X demo
in [ASM]
|
Prev: masm linking from console
Next: NASM HelloWorld - DOS
From: Phil Carmody on 21 Jul 2007 09:30 "Rod Pemberton" <do_not_have(a)nowhere.cmm> writes: > "santosh" <santosh.k83(a)gmail.com> wrote: > > case 0x05: > > { > > la[j-1] = la[j] / la[j+1]; > > j--; > > break; > > } .... > I.e., assuming LALR(1) and applying precedence, the above is: Parsing/precedence and order of evaluation are utterly utterly utterly unrelated. And by "the above" do you mean "the original", not "the above", as the above is certainly nothing like the below? > case 0x05: > { > --j; > la[j] = la[j] / la[j+1]; > break; > } > > It appears that DJGPP (GCC) works properly Nope. There is no properly. > while OpenWatcom v1.3 fails. Nope. There is no success, so there is no fail. > I'd > guess that most K&R style compilers work. Take this to c.l.c and have a bunfight, which you will lose, there. Stop trying to confuse a.l.a readers. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Herbert Kleebauer on 21 Jul 2007 12:19 "T.M. Sommers" wrote: > Rod Pemberton wrote: > >>>case 0x05: {la[--j] = la[j] / la[j+1]; break;} > > I.e., assuming LALR(1) and applying precedence, the above is: > > case 0x05: > > { > > --j; > > la[j] = la[j] / la[j+1]; > > break; > > } > > > > It appears that DJGPP (GCC) works properly while OpenWatcom v1.3 fails. I'd > > guess that most K&R style compilers work. > > The origial line invokes undefined behavior; anything the > compiler does is "proper". Then you have a very bizarre definition of "proper". It isn't a problem when the behaviour for such a construct is undefined in the C specification. The problem arises when an implementation of the C specification defines the behaviour for this construct. If the behaviour would still be undefined in the implementation, then the compiler would emit an error message an stop if it encounter this construct. It would be also no problem if all compilers would implement the same behaviour (and so extend the C specification in a consistent manner). But just to define the behaviour in the implementation (which isn't defined in the specification) and only emit a warning is a serious bug. At least the compiler should give an error message, even when all warnings are disabled. C is a very simple to use language (at least in the old K&R form). You don't have to "learn" it, looking at a few simple examples is enough to get you started. But how should you get aware of the problem with a construct like "la[--j] = la[j] / la[j+1];" if it exactly does what you suppose it to do with the compiler you use? I only noticed this problem when I compiled a program on a SUN and it didn't work properly. And as you see from this thread, even I'm now aware of the problem, this types of construct are still in the code I wrote a long time ago. Cross posted to comp.compilers and comp.lang.c (somebody has to tell them, that they should implement a proper error reporting routine in there compilers). Followup-To set to alt.lang.asm
From: Betov on 21 Jul 2007 13:01 Herbert Kleebauer <klee(a)unibwm.de> �crivait news:46A2320F.545B8132 @unibwm.de: > You don't have to "learn" it Right: I did that very carefully. :] Betov. < http://rosasm.org >
From: Hans-Peter Diettrich on 21 Jul 2007 12:58 Herbert Kleebauer wrote: >>>>>case 0x05: {la[--j] = la[j] / la[j+1]; break;} > > >>>I.e., assuming LALR(1) and applying precedence, the above is: >>>case 0x05: >>>{ >>> --j; >>> la[j] = la[j] / la[j+1]; >>> break; >>>} The assignment is the last operation in the whole expression (lowest precedence), so that the --j will occur most probably just before the assignment, after evaluation of the RHS expression, and during evaluation of the LHS. DoDi
From: Phil Carmody on 21 Jul 2007 13:44
Hans-Peter Diettrich <DrDiettrich1(a)aol.com> writes: > Herbert Kleebauer wrote: > > >>>>>case 0x05: {la[--j] = la[j] / la[j+1]; break;} > > > >>>I.e., assuming LALR(1) and applying precedence, the above is: > >>>case 0x05: > >>>{ > >>> --j; > >>> la[j] = la[j] / la[j+1]; > >>> break; > >>>} > > The assignment is the last operation in the whole expression (lowest > precedence), so that the --j will occur just after Scott Nudds flies out of your nose and hits your monitor. > most probably just before the > assignment, after evaluation of the RHS expression, and during > evaluation of the LHS. Please take your off-topic incorrect nonsense to comp.lang.c. When you've got the flaming you deserve, hopefully you will not post it anywhere else again. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./. |