vulcan@uiuc.edu (EvilTwin) (06/21/91)
In article <902@adimail.UUCP> tel@adimail.UUCP (Terry Monks) writes: >(Peter van der Linden (linden@adapt.Eng.sun.com)) scripsit: >> >> q = q++; >> > >This strange statement does exactly what I expected it to do - it assigns to >q the value of q incremented - i.e. is the same as just q++. I actually compiled >it to make sure. > > >Terry "" Monks > The above has been shameless edited of all (most?) simmerage. A co-worker and I tried the above on our respective machines. He on an IBM 70/386 using Borland C++, I on a MicroVAX II using DEC's C version 3.1. He received a result of 6, I one of 5. Why is this? Does your chewing gum lose it's flavor on the bedpost overnight? Evil "Bring on the Terry's" Twin - ps - the initial value of q was 5.
jfw@ksr.com (John F. Woods) (06/25/91)
vulcan@uiuc.edu (EvilTwin) writes: >In article <902@adimail.UUCP> tel@adimail.UUCP (Terry Monks) writes: >>(Peter van der Linden (linden@adapt.Eng.sun.com)) scripsit: >>> q = q++; EWW! >A co-worker and I tried the above on our respective machines. He on an IBM >70/386 using Borland C++, I on a MicroVAX II using DEC's C version 3.1. He >received a result of 6, I one of 5. Why is this? Why is this? You used two different compilers to compile an undefined expression. Why 5 and 6? 5 is the reasonable result of compiling into code like TMP := q ; value of postincrement is old value q := q+1 ; do postincrement q := TMP ; do assignment and 6 corresponds to TMP := q ; value of postincrement is old value q := TMP ; do assignment q++ ; take care of postincrements left over in expression Depending on the actual hardware and software architecture, either of these is a perfectly reasonable approaches to take (of course, a decent compiler would probably be able to reduce them to zero or one machine instructions respectively). As to why it is undefined, read The Standard and the FAQ, alternately, until either you reach enlightenment or your head explodes. Note that because it is *undefined*, the compiler was perfectly at liberty to generate q := 666 ; special marker for evil constructs or JSR _cpu$detonate or any other damned thing it liked.
jma@reef.cis.ufl.edu (John 'Vlad' Adams) (06/26/91)
In article <1991Jun25.151408.1024@ux1.cso.uiuc.edu> vulcan@uiuc.edu (EvilTwin) writes: >A co-worker and I tried the above on our respective machines. He on an IBM >70/386 using Borland C++, I on a MicroVAX II using DEC's C version 3.1. He >received a result of 6, I one of 5. >ps - the initial value of q was 5. My platform, an Amiga, with SAS C 5.10a, also generates a 5. Long live DECs and Amigas. :) -- John M. Adams --*****-- Professional Student /// Internet: jma@cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga Support, StarNet BBS \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
imc@prg.ox.ac.uk (Ian Collier) (06/26/91)
I have noticed quite a lot of talk recently about things like this... In article <4210@ksr.com>, jfw@ksr.com (John F. Woods) wrote: >Note that because it is *undefined*, the compiler was perfectly at >liberty to generate > q := 666 ; special marker for evil constructs >or > JSR _cpu$detonate >or any other damned thing it liked. Now I was just wondering, is there any statement in the ANSI standard which prohibits self-destruction of the CPU or any similar behaviour which might be physically dangerous or expensive? If not, do you think such limits would be reasonable to include? I mean, I suppose it might be quite easy to type: q = q-- instead of what you really meant: q = q-p and if your computer were to blow up unexpectedly you might get rather upset (if you were still alive to be upset, that is). Oh yes, :-) :-) :-) :-) :-) :-) :-) :-) :-) Ian Collier Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk
rob@raksha.eng.ohio-state.edu (Rob Carriere) (06/27/91)
In article <946.imc@uk.ac.ox.prg> imc@prg.ox.ac.uk (Ian Collier) writes: [undefined programs leading to] JSR _cpu$detonate > >Now I was just wondering, is there any statement in the ANSI standard >which prohibits self-destruction of the CPU or any similar behaviour >which might be physically dangerous or expensive? Contrariwise, it is a subtle consequence of a little-known appendix to the Standard that all undefined behavior must in fact include the exercise of lethal force on the programmer. This is known as the Standard review of the public. >If not, do you think such limits would be reasonable to include? I believe they're considered a Common Extension. >Oh yes, > :-) :-) :-) :-) :-) :-) :-) :-) :-) Indeed? SR ---
carroll@cs.uiuc.edu (Alan M. Carroll) (06/27/91)
In article <946.imc@uk.ac.ox.prg>, imc@prg.ox.ac.uk (Ian Collier) writes: > I have noticed quite a lot of talk recently about things like this... > > In article <4210@ksr.com>, jfw@ksr.com (John F. Woods) wrote: > >Note that because it is *undefined*, the compiler was perfectly at > >liberty to generate > > JSR _cpu$detonate > Now I was just wondering, is there any statement in the ANSI standard > which prohibits self-destruction of the CPU or any similar behaviour > which might be physically dangerous or expensive? If not, do you think > such limits would be reasonable to include? Think of it as Evolution in Action. You have two populations, compilers and their natural prey, programmers. Compilers that have better quality will preserve programmers better, and prosper. Those that eat their programmers too frequently will run out of users and expire. -- Alan M. Carroll <-- Another casualty of applied metaphysics Epoch Development Team Urbana Il. "I hate shopping with the reality-impaired" - Susan
rmp@crashnburn.Eng.Sun.COM (Richard Pottorff) (06/28/91)
In article <29378@uflorida.cis.ufl.EDU> jma@reef.cis.ufl.edu (John 'Vlad' Adams) writes: In article <1991Jun25.151408.1024@ux1.cso.uiuc.edu> vulcan@uiuc.edu (EvilTwin) writes: >A co-worker and I tried the above on our respective machines. He on an IBM >70/386 using Borland C++, I on a MicroVAX II using DEC's C version 3.1. He >received a result of 6, I one of 5. >ps - the initial value of q was 5. #My platform, an Amiga, with SAS C 5.10a, also generates a 5. #Long live DECs and Amigas. :) -- John M. Adams --*****-- Professional Student /// ^^^^^^^^^^^^^^^^^^^^ I would be too, but it doesn't pay enough :-) I tried this two ways on my Turbo Pascal Compiler at home. int q=0; printf("\nq=q++=%d", q=q++); q=q++=0; and: q=q++; printf("\nq=%d", q); q=1 I don't know what this proves. Ramblin Rick
tmkk@uiuc.edu (K. Khan) (06/29/91)
In article <15952@exodus.Eng.Sun.COM> rmp@crashnburn.Eng.Sun.COM (Richard Pottorff) writes: > >I tried this two ways on my Turbo Pascal Compiler at home. > ^^^^^^^^^^^^^^^^^^^^^ > >int q=0; >printf("\nq=q++=%d", q=q++); > >q=q++=0; > >and: > q=q++; > > printf("\nq=%d", q); > > q=1 You did? And it compiled?!?!?!?!?!?!? >I don't know what this proves. It proves that you don't know the difference between a Pascal compiler and a C compiler! ;-) ;-) ;-) ;-) ;-)