Path: utzoo!attcan!uunet!samsung!think!snorkelwacker!apple!oliveb!orc!decwrl!granite.pa.dec.com!mwm From: mwm@raven.pa.dec.com (Mike (Under Construction) Meyer) Newsgroups: comp.sys.amiga.tech Subject: Re: __chip is evil Message-ID: Date: 12 Jan 90 05:20:28 GMT References: <85006@linus.UUCP> <4839@sugar.hackercorp.com> <86113@linus.UUCP> Sender: news@decwrl.dec.com Organization: Missionaria Phonibalonica Lines: 66 In-reply-to: duncant@mbunix.mitre.org's message of 9 Jan 90 05:47:57 GMT Section 4.1.2 of (my draft of) the ANSI standard states that "All external identifiers that begin with an underscore and iether an upper-case letter or another underscore are reserved." However, this simply means that these identifiers may be defined in standard header files, so the user should not use these names. The standard does NOT say that the implementor may use these identifiers to change the syntax of the C language, as you are doing when you introduce things like "__chip". You're right - they don't say you can use them to "change the syntax of the language", or even as type qualifiers (which is what Lattice is actually doing). On the other hand, the standard does give implementors a lot of leeway on extensions. Enough so that, even if it accepts __chip, a compiler can be a conforming implementation. And a program that uses __chip can be a conforming program. See section 1.7, especially the footnote that says that "conforming programs may depend upon non-portable features." Also, one of the key arguments against noalias was that there was no prior art, and thing like it should be done as extensions to a standard without it, so that there will be prior art for the next standard. Or, simply put, __chip is not a violation of the standard - it's an extension that the standards committee allowed for. [Homework question: why is the Lattice chip keyword (instead of __chip) a violation of the standard?] I'm sorry, but I can't find this in the standard. Can you direct me to the appropriate paragraph? Or perhaps this is something from the "Rationale"? Once again, you're right - there is no specific statement in the standard that says that you can't change the semantics of the program with #pragma. Of course (as with __chip), you have to look at the entire standard before you can rule that out. There are people who sat on the standards committee who claim that #pragma can't change the semantics of the program. There are also acknowledged authorities who says that it can. It'd be nice if this were cleared up in the final version, but it's not really important (see below). Again, I think that you guys are missing the point. It seems to me that the ANSI committee provided #pragma exactly for handling non-standard things, such as "__chip", which can't otherwise be done in the language. I think you're missing the point - it doesn't really matter. The only machine which is likely to have the need for __chip is an Amiga. Programs which use it almost certainly won't run on other hardware. Programs which are strictly conforming will compile whether or not __chip is supported. What does matter is whether any other compilers that provide support for declaring data structures to be in chip memory follows the lead already set by Lattice. Failure to do so calls for castigation of the implementors, just as lattice should be castigated for using instead of . You'd be using your time a lot better trying to convince people about to create an incompatable compiler to not do so rather than trying to change the minds of people who have working code that uses an existing feature.