Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: I can't find a good definition anywhere...
Message-ID: <10267@smoke.BRL.MIL>
Date: 15 May 89 20:47:16 GMT
References: <1954@trantor.harris-atd.com> <10084@smoke.BRL.MIL> <14327@bfmny0.UUCP> <4190@ficc.uu.net>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <4190@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>#pragma model(large)
>#pragma segment(code,romcode)
>#pragma byteorder(bigendian)
>#pragma generate(80386)
>#pragma flags(-I/usr/X/include -L/usr/X/lib)
>#pragma list(full)
>#pragma import(getchar from romlib.iolib,putchar from romlib.iolib)
>#pragma list(dumpmacros)

I think all the above would be valid use of #pragma.

>#pragma inline(getchar,putchar,strcmp,strcpy,strlen)
>#pragma rename(strlen,Strlen)

These two would probably be valid, depending on how the details are handled.

>#pragma interface(plm/386,dq$delete)
>#pragma ada(FUNCTION WHATEVER IS...)

I don't know what these mean.

>#pragma noalias(main.argv)
>#pragma enable(gcc_expressions)

To the extent that strictly conforming code may have its behavior altered
by these, I don't think they're valid.

>#pragma asm(mov %fp(2),%fr0)
>#pragma enable(pascal_strings)

These seem to cause readily detectable alteration of semantics and thus
would not be valid.