🚀 go-pugleaf

>In <1990Nov2.034300.3065@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes:
>>In article <MEISSNER.90Oct30121525@osf.osf.org> meissner@osf.org (Michael Meissner) writes:
mm>>>When I worked at Data General on the MV C compiler, I added sizeof
mm>>>support to the preprocessor
nd>>As I understand the standard, a conforming processor is not allowed to
nd>>support this extension, even with a warning, even with a #pragma, etc.
rs>Others have replied to other aspects of this issue.  I just wanted to add 
rs>that everything is allowed via a #pragma.  X3J11 reaffirmed at some point
rs>that the behavior of any program with a #pragma is implementation defined,
rs>so a #pragma can do anything.
 
If this is really true, it defeats the purpose of #pragma.  My understanding
was that #pragma may have any implementation-defined effect WHICH does not
change the meaning of a conforming program (though it may change the effect
of a nonconforming program).  That definition would have been far more useful.
 
For example, a conforming program, optimized for processor ABC:
  struct some_tag {
  #pragma align 2
    unsigned x;
  #pragma align 1
    float y;
  };
  [the rest of a conforming program, using a struct some_tag]
On processor XYZ, which does not recognize #pragma align or which gives a
different meaning than processor ABC did, this conforming program would still
be guaranteed correct results, just not optimally, if my understanding was
correct.  But it may be given garbage results of Mr. Schubert's understanding
is correct.  I hope (truly) to hear that Mr. Schubert is mistaken.
--
Norman Diamond, Nihon DEC    diamond@tkov50.enet.dec.com
                                    (tkou02 is scheduled for demolition)
We steer like a sports car:  I use opinions; the company uses the rack.
From: root@cho.uucp (Operator)
Path: cho!root