🚀 go-pugleaf

In article <1989Jan16.204455.16091@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <8770@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>>... I plan
>>to make fairly extensive use of #pragmas in any future C tools I
>>might write, and I'd like to do so in a consistent and compatible
>>way...
>
>This statement is self-contradictory; #pragmas are implementation-dependent
>by definition, and any use you make of them will be inconsistent and
>incompatible with many other implementations.  This is not to say you
>shouldn't use them, but that you should think hard about the tradeoffs.

Yes, but are there any guidelines, however vague, about what a #pragma
line should look like?  I liked the original poster's suggestion of
#pragma utility-name whatever-garbage-the-utility-wants (e.g., #pragma
lint whatever).  I think it would be helpful if #pragma's weren't
totally implementation-dependent.  Order of evaluation of certain
expressions is also "implementation-dependent," and the clear message
is not to count on it under any circumstances.  Is the same to be true
of #pragma's?  At the very least, I'd like to not have to worry that
my #pragma gnuc's will conflict with my #pragma lint's and #pragma
turboc's.  Are there any guidelines or even hints to developers to
help avoid #pragma namespace conflicts?  It would be a boon to
developers and programmers alike if there were, I think.


      /|/| Joe English
-----< | | 
  O   \|\| english%lipari@oberon.usc.edu