peter@sugar.hackercorp.com (Peter da Silva) (01/12/90)
[ to comp.std.c folks: the discussion is the use of __id for nonportable qualifiers in declarations, like Microsoft does with __far. ] > >Names beginning with two underscores or one underscore and an uppercase > >letter are reserved to the implementation and may be used for any purpose > >the implementer desires. Names beginning with one underscore and anything > >but an uppercase letter may be used with file scope, but as externals are > >reserved to the implementation. > 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. What it means is that a portable C program will not use those names for any purpose. So it's safe to use them for a non-portable extension to the language, because you will not break any portable programs. > 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". And it doesn't say the implementor can't do this either. In practice it means it's guaranteed to be safe to use them for this purpose. > >On the other hand #pragma is not allowed to change the semantics of a > >program. > I'm sorry, but I can't find this in the standard. Can you direct me to > the appropriate paragraph? Anyone in comp.std.c want to take a crack at it? It certainly gets brought up often enough over there... Certainly #pragma is a lot less elegant: static __chip ushort icon[4+ISIZE]; Or: #pragma chip(icon) static ushort icon[4+ISIZE]; -- Peter "Have you hugged your wolf today" da Silva <peter@sugar.hackercorp.com> `-_-' 'U` "I haven't lost my mind, it's backed up on tape somewhere"
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/13/90)
In article <4919@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >[ to comp.std.c folks: the discussion is the use of __id for nonportable > qualifiers in declarations, like Microsoft does with __far. ] That's not only a proper use of __*, but the recommended one. >> >On the other hand #pragma is not allowed to change the semantics of a >> >program. >> I'm sorry, but I can't find this in the standard. Can you direct me to >> the appropriate paragraph? >Anyone in comp.std.c want to take a crack at it? My argument is that the entire Standard must be conformed to, whether or not an application happens to actually use #pragma, thus #pragma cannot change the semantics that rest of the Standard specifies. However, opinion on this does not appear to be unanimous even among X3J11 members. This is another area where a formal interpretation ruling would be nice.
tneff@bfmny0.UU.NET (Tom Neff) (01/13/90)
In article <11939@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >My argument is that the entire Standard must be conformed to, whether or >not an application happens to actually use #pragma, thus #pragma cannot >change the semantics that rest of the Standard specifies. Or else what? Speaking of semantics! If an implementation conforms exactly to the Standard, EXCEPT that it happens to support some extension like #pragma allow_some_crappy_old_aberration_from_1981 which, IF you include that line, allows it to compile a non-conformant program, then do we cry "ooh! bad mans!" and deny conformance to the whole product? In other words, must a conforming IMPLEMENTATION be incapable of accepting any kind of nonconforming SOURCE PROGRAM, no matter what extra control switches you feed it? If so -- if vendors would be unable to claim ANSI conformance for any new compiler release which retains any special backward compatibility or special extensibility -- then the Standard will be the VERY proud sovereign of a VERY tiny kingdom indeed... :-) -- "NASA Awards Acronym Generation :(%( : Tom Neff System (AGS) Contract For Space : )%): tneff%bfmny@UUNET.UU.NET Station Freedom" - release 1989-9891 :(%( : ...!uunet!bfmny0!tneff
henry@utzoo.uucp (Henry Spencer) (01/14/90)
In article <4919@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> >On the other hand #pragma is not allowed to change the semantics of a >> >program. > >> I'm sorry, but I can't find this in the standard... > >Anyone in comp.std.c want to take a crack at it? ... This is an issue which simply cannot be decided from the text of the standard. The usual "not allowed" argument is that the #pragma section must be read together with the rest of the standard, not in isolation, and therefore #pragma's "implementation-defined" effect is limited by the rest of the standard. The counterargument is that the rest of the standard must be read together with the #pragma section, i.e. with the possibility that #pragma may have implementation-defined effects on the rest of the standard. Both interpretations are self-consistent, and there is nothing in the standard that decides between them. In practice, people *will* implement #pragmas that have semantic effects. -- 1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology 1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/15/90)
In article <15093@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >In article <11939@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>My argument is that the entire Standard must be conformed to, whether or >>not an application happens to actually use #pragma, thus #pragma cannot >>change the semantics that rest of the Standard specifies. >Or else what? Speaking of semantics! Or else the implementation does not conform to the Standard. What else? >In other words, must a conforming IMPLEMENTATION be incapable of >accepting any kind of nonconforming SOURCE PROGRAM, no matter what >extra control switches you feed it? The requirements on a conforming hosted or freestanding implementation are spelled out in section 1.7 of the Standard. Programs naturally have different requirements, and two categories of program conformance are identified: conforming and strictly conforming. Some forms of extensions may be supported and others may not. These constraints are spelled out through the Standard. In particular, keywords such as __chip and __far may have semantic effect; a strictly conforming program must not contain these, but a conforming program may if some implementation accepts them. Strictly conforming programs are intended to be maximally portable among conforming implementations (i.e. they are expected to work with no editing required when moving to another conforming environment, subject of course to resource limits etc.). Because unrecognized #pragmas are required to be ignored, and since there is no standard interpretation for the contents of #pragmas, I conclude that the intention is for #pragmas to not alter the run-time I/O behavior of programs, i.e. "semantics" (execution speed may be affected, though). The way that compiler vendors generally address the issue of backward compatibility is to provide compiler "switches" or "options" that alter the compiler behavior. From the C Standard point of view, each combination of switches corresponds to a separate implementation, some of which may be conforming and some of which may not. It is the responsibility of the vendor to indicate at least one method of invoking the compiler (and linker, and run-time support) that will produce conformance to the Standard.
khb@chiba.kbierman@sun.com (Keith Bierman - SPD Advanced Languages) (01/16/90)
In article <11939@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: ... That's not only a proper use of __*, but the recommended one. >> >On the other hand #pragma is not allowed to change the semantics of a >> >program. My argument is that the entire Standard must be conformed to, whether or not an application happens to actually use #pragma, thus #pragma cannot change the semantics that rest of the Standard specifies. .... I would have thought that something like #pragma K&R would be highly desired, for those cases where the traditional unix interpretation of K&R has been different ..... Is everyone that certain that old codes don't matter anymore ? Or is this not the preferred "spelling" ? I haven't been that hip to C standards discussions (only about a month of watching the group and such), so I apologize if this is an old discussion come back from the dead. cheers -- Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks
guy@auspex.auspex.com (Guy Harris) (01/17/90)
>I would have thought that something like > >#pragma K&R > >would be highly desired, for those cases where the traditional unix >interpretation of K&R has been different ..... How about the "-Xt" flag, such as, if I remember correctly, appears in AT&T's S5R4 C compiler? The "traditional UNIX interpretation of K&R" didn't include "#pragma", so the proper response of the compiler to such a #pragma might be to turn the "K&R" flag on and then reject the "#pragma".... :-) More to the point, it's probably easier to whack your Makefile to put in "-Xt", or some such flag (I think GCC has a similar flag, but with a different name) than to whack all your source files to include the "#pragma". >Is everyone that certain that old codes don't matter anymore ? Or is >this not the preferred "spelling" ? "Spelling" of what? I prefer "programs" to "codes", myself, but then I don't really come from the scientific programming community. :-) No, I don't think anyone's certain that C programs written to older C semi-standards and implementations don't matter. However, they may not think that a "#pragma" is the right solution, either....
gwyn@smoke.BRL.MIL (Doug Gwyn) (01/17/90)
In article <2821@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >"Spelling" of what? I prefer "programs" to "codes", myself, but then I >don't really come from the scientific programming community. :-) They're called "codes" because you have to be a cryptanalyst to decipher them.