Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!yale!root From: root@yale.UUCP (Celray Stalk) Newsgroups: comp.sys.atari.st Subject: Re: A Lesson Learned Message-ID: <54349@yale-celray.yale.UUCP> Date: 21 Mar 89 18:09:24 GMT References: <8903202254.AA00303@icase.edu> Reply-To: fischer-michael@CS.YALE.EDU (Michael Fischer) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 51 In article <8903202254.AA00303@icase.edu> csrobe@ICASE.EDU (Charles S. [Chip] Roberson) writes: >Greetings fellow psycho-programmers! Well, I just learned a lesson today >and I thought I pass it on to any others who haven't learned this, yet. >It only blew a day and a half of my time. > >Below is a pretty slick fprintf() statement from some of the UUPC/ST code >munged enough to simplify this example. Looking at it, I was sure that it >should work. I mean, why not? It's pretty straight forward -- pass >fprintf() 3 arguments: stderr, the appropriate format string, and finally >the desired value to print. Then once the value is passed, increment. >Right? Wrong! > >-------------------------------------------------------------------------- > fprintf( stderr, isprint(*cp)? "[%c]":"[%02x]", *cp++ ); >-------------------------------------------------------------------------- > >The moral of this story? Well, as my Theory of Prog. Lang prof would >say, "That's just another insecurity of C!"; to which he would add >"Ada is a much better language." Well, I guess I would say >"Hey! Be careful out there." > >Seriously, this is one side-effect that I hadn't thought about. How >do other ST compiler's pass their parameters? So much for portability, >eh? Does anybody know how the dpANS standard would affect this, if at >all? I can't seem to remember anything in it that would. This is a valuable lesson for people to learn: don't write code that depends on undefined features of a language. Order of evaluation of operands in expressions is not defined in many languages, Ada and C included (excecpt for logical operators and the "," operator in C). This means that code such as the above that depends on order of evaluation is not correct and certainly not likely to be portable. One might want to know out of curiousity in what order other ST comiplers pass their parameters, but you should never write code that depends on this knowledge since it will not be correct according to the language definition and will not be portable. Operators to be careful of in C include ++, --, =, etc., but also function calls. For example, z = f(x) + y; can have unpredictable results if f happens to change y. Even with assignment statements, you can't assume the right hand side will be completely evaluated before the left, e.g. { x=1; a[x++] = x + 3; } might cause either 4 or 5 to be stored into a[1], depending on when your compiler chooses to evaluate the subscript. ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ==================================================