Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!wanderer.nsi.nasa.gov!root
From: root@wanderer.nsi.nasa.gov (Michael C. Newell)
Subject: Re: Who has had success with xview 3.0?
Message-ID: <1993Jun26.004451.5244@news.arc.nasa.gov>
Keywords: xview 3.0
Sender: usenet@news.arc.nasa.gov
Organization: NASA Ames Research Center, Moffett Field, CA
References: <C91FHt.LCB@ra.nrl.navy.mil> <1993Jun24.013940.20757@news.arc.nasa.gov> <20f82lINNc54@bonnie.tcd-dresden.de>
Date: Sat, 26 Jun 1993 00:44:51 GMT
Lines: 61
In article <20f82lINNc54@bonnie.tcd-dresden.de>, j@bonnie.tcd-dresden.de (J Wunsch) writes:
|> In article <1993Jun24.013940.20757@news.arc.nasa.gov> root@wanderer.nsi.nasa.gov (Michael C. Newell) writes:
|> >I had a LOT of problems, until I started looking for constructs
|> >of the form "something = case ? value1 : value2". I changed
|> >them to "if (case) something = value1; else something = value2;"
|> >and it cleaned up the problem. I've had this same problem with
|> >a number of other c compilers; I don't understand why, but
|> >changing the code as above fixes it every time.
|> >
|> But it's really a difference. While ``a = b? c: d'' is just an
|> expression (it's only made a statement if you just add a semicolon),
|> ``if(b) a=c; else a=d;'' is always a statement. Thus, there might
|> be cases where you can't workaround your way, since the resulting
|> value of the expression is being used elsewhere. (A statement ain't
|> got a resulting value.)
|>
True. In many of the cases they had something like
routine(...,a?b:c,...);
which I changed to
if (a) routine(...,b,...); else routine(...,c,...);
which is even worse - it's not just a statement; it's a block!
However, chaning out the "a?b:c" expressions ALWAYS fixed (sorry,
circumvented) the hanging problem. Unfortunatey there are a
couple of cases like
routine(...,a?b:c,...,d?e:f,...);
which aren't as easy to work around. In those cases, I used
{ <type> temp1 = c; if (a) temp1 = b;
<type> temp2 = e; if (d) temp2 = f;
routine(...,temp1,...,temp2,...);
}
which is REALLY horrible; however it's the only way I've found
to get around the problem.
|> For my experience, gcc's handling of those expressions isn't broken
|> anyway. So if it brakes some code, it must be the program itself.
Perhaps so. However, no matter how broken the input to the compiler
is, it (the compiler) SHOULD tell you you have broken input; not hang.
I think it's really interesting that I've seen this in other compilers
(the early VAX C had the same problem, and I also recall it being a
problem with one of the MS-Doze compilers.)
|> The operator precedence rules appear to be a bit mysterious. Espec-
|> ially, if you look at precedence of comma and assignment operators.
|> In case of not being obvious, simply set a pair of paren's around
|> the expression in question.
The precedence rules are well defined. *IF* you happen to be a
compiler. For those of us that have to remember that stuff... ;{(
Mike Newell
NASA Advanced Network Applications