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: FORTH on the Advanced Placement Computer Science ! Date: Fri, 16 Jan 2015 13:44:35 -0800 Organization: A noiseless patient Spider Lines: 120 Message-ID: <87ppaemmd8.fsf@jester.gateway.pace.com> References: <20141226022222.6f32fe7f@maxa-pc> <7xd277yybp.fsf@ruckus.brouhaha.com> <7xbnmquimp.fsf@ruckus.brouhaha.com> <3d03e403-7181-4ab3-8a2f-a23d0c4843f7@googlegroups.com> <87y4pt4qkl.fsf@jester.gateway.sonic.net> <2014Dec27.111715@mips.complang.tuwien.ac.at> <878uhs4zxk.fsf@jester.gateway.sonic.net> <871tnd9dg0.fsf@jester.gateway.pace.com> <87387q5hi8.fsf@jester.gateway.sonic.net> <87iogkweeq.fsf@jester.gateway.sonic.net> <87mw5stw3h.fsf@jester.gateway.sonic.net> <8d599454-5ef7-4fac-a2c1-b0a125e4f048@googlegroups.com> <87bnm7sr1u.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="cf2250d04a15656821738afa87e3379c"; logging-data="13753"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5z4YftCjwYN05riFa1KII" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:/UT3U8iinEm1CU6Shn6dk6LR6FE= sha1:bHrr3tLC9rBcutHVBDi9OWudybI= Xref: csiph.com comp.lang.forth:35853 Bernd Paysan writes: > No, I always refuted your argument by pointing to the same parts of the C > standard, which tell you different, but it never sinks into your brain. I'd say you gave your personal interpretation of the text of the standard, which isn't a crazy interpretation but which hasn't gotten that much traction (that I know of) with implementers (gcc/llvm), academics (Regehr, etc) or the standards committee. Note that the passage you cited talked about erroneous input and consider that "erroneous" means "invalid" (synonym shown at thesaurus.com). > It includes invalid programs, but also includes pretty valid > non-portable programs. Non-conformant programs are valid only if the documentation for the local environment says they are. So if the ANSI says that signed integer overflow is undefined and the local environment doc (GCC manual in this case) doesn't say otherwise, then it's invalid. In the GCC 2.95 era the compiler manual specified wrapv behavior for signed overflow, so your claim that an overflow-triggering program is merely non-portable (instead of invalid) made sense in that environment. In other environments whose docs don't include such a statement, you're simply making unjustified assumptions. >> The [committee's] belief [is] ... that they are specifying an HLL >> that enables ultra-aggressive optimization > No, they aren't. Please cite the place where they do so. That's my summary of long discussions and debates with committee members (mostly one person, but still). There's not a single document I can point to. But here's an old post that gives some of the flavor: https://groups.google.com/forum/message/raw?msg=sci.crypt/uPyldDtWV_Y/GubXCyF-o-4J The guy who wrote that post was on the ANSI C committee and gave various justifications for particular constructs being undefined because of optimizations they enabled. IIRC he was a supercomputer programmer at some military site, so he probably placed higher emphasis than most of us about squeezing every drop of speed out of code. He wrote stuff like that all the time. Unfortunately Google Groups has gotten almost impossible to use so I'm not in a position to hunt down more quotes, but that sci.crypt thread is likely to have more. http://blog.regehr.org/archives/1180#comment-16431 is not from a committee member AFAIK, but also illustrates that viewpoint about C: UB is the only thing that has kept C compilers ahead of other languages in terms of performance, and by extension, the only thing that has kept C alive for so long. If you remove all of the small competitive advantages that keep C “fast”, then it may as well not exist as a language, since it has *very* little else going for it, except for providing an system ABI for others to build on. >> Early versions of GCC launched a Rogue game if you used a #pragma > Actually, in the meantime, the GCC maintainer found a few uses for #pragma, > but continue to use __attribute__ ... > https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html I remember a few more details of that situation now, and your Pragmas.html link refers to it indirectly. RMS didn't like #pragma because the standard didn't permit generating them from preprocessor #defines. So (when there was no inline keyword) you might want to use an "inline" pragma optionally on a bunch of different functions, like #if LOTS_OF_RAM #define INLINE #pragma inline #else #define INLINE #endif INLINE f() { ... } INLINE g() { ... } but that wasn't allowed by the cpp specification. RMS complained about this to the committee (along with a lot of other things) but they didn't accept his advice about it, so he considered #pragma to be useless and __attribute__ to be better. Having #pragma launch a game was one way he showed his disapproval. The link you posted says C99 introduces the _Pragma operator. This feature addresses a major problem with ‘#pragma’: being a directive, it cannot be produced as the result of macro expansion. _Pragma is an operator, much like sizeof or defined, and can be embedded in a macro. which means the committee finally fixed the problem RMS complained about 10+ years earlier, before even the first version of the standard was approved, and that had inspired the rogue-launching hack. So now I guess _Pragma can be used instead of __attribute__ . > RMS is a Lisp guy, he would never think of C as a high level language, > but he did a quite good job at making it a portable assembler There's a proposal for a "friendly dialect of C" that you might like: http://blog.regehr.org/archives/1180 I notice most of the support in the comments comes from embedded developers. I think at the time C was first standardized, there may have been an unnoticed divide between the embedded programmers and the HPC programmers: the stuff you're saying is reasonable from the embedded side, but doesn't really acknowledge the desires of the HPC side or how those desires influenced the standard. These days there's a third set of concerns arising from internet security that turns C into nightmare. Meanwhile, I recently learned the really cool German word "Gretchenfrage", a question that cuts to the center of an issue. Suppose the "friendly" C dialect is implemented in GCC, and suppose it's even made the default, so to get all that UB you have to use the "-faggressive-ansi" option. I know that lots of the gforth development work went into making it fast, and lots of gforth-related publications contain benchmark data comparing it to competing Forths. You find that with -faggressive-ansi, gforth and gforth-fast still passes all their tests and runs 10% faster than with the friendly setting. So do you use the option? If yes, how are your complaints about ANSI legitimate? If not, what does that say about your confidence in your development skills and testing processes?