Path: csiph.com!usenet.pasdenom.info!aioe.org!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: Sun, 03 May 2015 17:22:04 -0700 Organization: A noiseless patient Spider Lines: 59 Message-ID: <87fv7d2nv7.fsf@jester.gateway.sonic.net> References: <87pp73wi24.fsf@jester.gateway.pace.com> <87a8y695hs.fsf@jester.gateway.pace.com> <87d232wtfp.fsf@jester.gateway.pace.com> <630fc3d6-4917-426d-88f3-6e0179c1ad70@googlegroups.com> <878udqwq0s.fsf@jester.gateway.pace.com> <2015Apr18.164117@mips.complang.tuwien.ac.at> <874mo5mkpn.fsf@jester.gateway.sonic.net> <2015May2.125317@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="22184b02e80198190244f5a2dd813f11"; logging-data="24744"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/mDFLC8y8U+UR61hV2BvOg" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:daVWg87iVZoq7NeZ3KphiLw2IrE= sha1:4lppybRNNwBBd9uL/gMsGrOgrUc= Xref: csiph.com comp.lang.forth:38805 anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>The standard was written with those optimizations in mind > You repeat that claim without supplying evidence. Here are some posts from committee member Doug Gwyn, concerning a UB when a variable is read and modified without an intervening sequence point other than with autoincrement: 1. He explains that the UB is to enable special optimizations on vector machines: https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/7fSMidjs044J ...if a swath of a vector is being operated on it might be that nominally the "same" element has different values at different places in the pipeline. It is in order to avoid forcing the generated code to have to pessimistically flush pipelines etc. (nor to have to add a preliminary test of whether j == a[j]) that the default policy is to not require such pessimism by the implementation. 2. He says it's fine for a given code fragment to be UB as long as the standard gives the programmer a way to get the desired sequencing: https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/L9blvboMpL0J Even if it is "obvious" by Tom St Denis thought he meant by that source, in a real implementation one can have register caching, vector instructions, etc. which all could make the fast code that almost every user would expect to be generated produce an effect different from what Tom thought it should be. The license for implementations to be *efficient* is important in the success of C as a systems programming language, and in order to prevent excessive liberties being taken by code optimizers the standard provides ways for programmers to *portably* and *reliably* express what they intend; the most notable tool in this regard being the sequence point guarantees. 3. Here he's explicit, C's philosophy is to generate fast code for careful users: https://groups.google.com/forum/#!original/comp.std.c/DP_WFjf1Ug0/xgVrnRbpV84J Rather than penalize *everybody* by default, we support the best code generation for the careful user by default, and when a more strict order of evaluation is necessary for the correctness of some algorithms there are ways for those programmers to obtain it. He was always writing stuff like that, and I got into long discussions with him that are now hard to find because of the crappy new interface of Google Groups. His basic attitude was that C programmers were supposed to use NASA-like processes to ensure freedom from UB and other errors. He blamed the whole phenomenon of buffer overruns on failure to use those processes. > As mentioned, P.J.Plaugers articles explaining what happened in the > C89 committee contained nothing of the kind. Are these articles online? Did they discuss the issue of UB at all?