__chip is evil

[Doug Gwyn]

In article <15093 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
>In article <11939 at smoke.BRL.MIL> gwyn at 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.