Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: rhel 7 and kforth Date: Fri, 17 Apr 2015 07:47:11 -0700 Organization: A noiseless patient Spider Lines: 92 Message-ID: <87a8y695hs.fsf@jester.gateway.pace.com> References: <6b95db78-ff4c-42aa-9680-7e4e588f61a4@googlegroups.com> <29c7eb53-229e-40a4-9bad-0d14e953ebc3@googlegroups.com> <87f18d43-a91e-4ae7-b98a-2cf4b7227c47@googlegroups.com> <87y4lrwpfo.fsf@jester.gateway.pace.com> <87twwfwlm2.fsf@jester.gateway.pace.com> <87pp73wi24.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="bda44be170c76b3ef6d23fecd204a8fa"; logging-data="8171"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++MX0sfH8WbM+e82OAlzTF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:yk091eOq9X+nRkhBJ03ozM74H94= sha1:rtn1ZZzrrO4tDgtwC7ui12vsM1Q= Xref: csiph.com comp.lang.forth:38274 krishna.myneni@ccreweb.org writes: > is there any existing C compiler which does anything different from > gcc with regard to compiling, a[i] = i++ ? It's difficult to tell whether even GCC 4.9 always does it the same way, or whether all existing versions of GCC do it the same way. So you can't count on it. > If not, it is absurd to write a standard that breaks universal > practice, There's no such thing as universal practice (literally everybody does it), there's only widespread practice, common practice, uncommon, etc. Any choice is going to annoy someone. The standards committee is tasked by the C community to make these choices and trade-offs and produce a document, the standard. After that, in the C world, such questions are resolved by the standard being the final word. As far as I know, this process works the way it's supposed to: the committee doesn't impose its weird stupid choices on a wider C community that wants something different. The committee really does do what the C community wants it to do. So those decisions you find objectionable are actually what the C community wants, or at least wanted back at the time the decisions were made. One could reasonably say the computing atmosphere has changed since then, so maybe the decisions should be revisited in some forthcoming revision, but we don't have that right now. > for the sake of some theoretical possibility of improved efficiency. I don't think it was a only theoretical. The idea was to allow compilers to generate faster code on machines with parallel execution units, and some compilers (I think including for the Cray supercomputer of the 1980's) really did that. What to do with "a[i] = i++;" was a topic of considerable discussion back then. The outcome wasn't an oversight or accident or a concession to some vendor who was too lazy to fix his compiler. Given a choice between doing X and getting fewer bugs, or doing Y and getting faster code, they chose faster code on the theory that C programmers are supposed to be hypervigilant. One finds a somewhat similar attitude in statements like "Forth is an amplifier". > the statement is unambiguous if one considers that i++ on the > rhs means to use "i" first in the expression, then increment it. Sure, and 2+3=9 if one considers that 3=7. C is simply not defined that way. "Do X, then do Y" in C jargon is phrased as "there is a sequence point between x and y". But we know that the assignment operator does not introduce a sequence point. Therefore the compiler is not required to use i on the lhs before incrementing it on the rhs. Another way to look at it is that the compiler is free to treat "a[i] = i++" as int i; ... int f() { return i++; } a[i] = f(); and in that case, the increment obviously happens before the subscript dereference. > This was certainly common practice among C programmers for many many > years. > I don't know if the ISO C standard revoked the distinction between > prefix and suffix use of the increment and decrement operators, but it > seems like it has effectively done so. No it hasn't. If you say "x = i++", x gets the old version of i. You only don't know whether the memory location holding i has already been incremented, at the time that the old value is copied to the location holding x. In the "a[i]=i++" case, that ambiguity matters because you don't know if the increment has happened when the location of a[i] is computed. > Yes, I see the compiler warnings for both examples with -Wall (output > below). For the moment, I will have to make a band-aid patch for > kForth, to deal with the (absurd) compiler problems of gcc 4.8 and > higher. It's not a compiler problem, it's a problem with C itself, which in turn stems from the optimization-crazed C culture that doesn't consider it to be a problem. More recently maybe there has been some movement about this, because the economics of computing have changed since these decisions were made, and we've seen the consequences of lots of bugs caused by C hazards. http://blog.regehr.org/archives/1180 might be of interest. > The better solution, for the next release, will be to rely less on the > C compiler, and move the functions to pure assembly language > implementations. That's one approach, but I think it's more accurate to say it's relying less on your knowledge of the C language.