Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: I can't find a good definition anywhere...
Message-ID: <10256@socslgw.csl.sony.JUNET>
Date: 16 May 89 04:58:32 GMT
References: <1954@trantor.harris-atd.com> <10084@smoke.BRL.MIL> <14327@bfmny0.UUCP> <4190@ficc.uu.net>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 75

In article <4190@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

>What do you think of:

>#pragma model(large)
IMHO I could live with this, though I'd rather see an option that is
settable in a pull-down menu (or flag on the command line, etc.).

>#pragma interface(plm/386,dq$delete)
This seems reasonable.

>#pragma segment(code,romcode)
This seems reasonable too.

>#pragma asm(mov %fp(2),%fr0)
I can think of lots of strictly conformant programs that will crash or
do various other obscure things when this pragma is added.  This is
exactly the kind of thing that should not be a pragma.  It was better
when asm() was simply a pseudo-function.  Or an #asm directive would
be better too.  This kind of effect deviates farther from the allowed
meanings of #pragma than anything else I can think of.

>#pragma noalias(main.argv)
Well, if this tells the truth when it is added to a strictly conformant
program, then it will not change the behavior of the program.  If it
tells a lie, then a strictly conformant program (which does alias that)
will be broken by the lie.  Technically this #pragma should not be
allowed, but IMHO I would allow it and let liars get what they ask for.

>#pragma byteorder(bigendian)
>#pragma generate(80386)
>#pragma enable(pascal_strings)
Same opinion as for model.

>#pragma ada(FUNCTION WHATEVER IS...)
Same opinion as for interface.

>#pragma flags(-I/usr/X/include -L/usr/X/lib)
MHO is obvious....

>#pragma enable(gcc_expressions)
This one would only be used in a non-conformant program, eh?  Anyway,
it would not change the meaning of a strictly conformant program, so
it seems fine to me.

>#pragma inline(getchar,putchar,strcmp,strcpy,strlen)
A strictly conformant program would not redefine these identifiers
anyway.  They would have to be the ones with the standard meanings,
so a compiler would already know if it's capable of inlining them.
Nonetheless this is in the spirit of #pragma, so I would allow it
even though it will usually be a no-op.  (I could imagine a #pragma
to *prevent* inlining though, to assist with debugging.)

>#pragma list(full)
Perfect.

>#pragma import(getchar from romlib.iolib,putchar from romlib.iolib)
Well, if you have a non-conformant program that wants to use these
functions without doing an #include [<"]stdio.h[>"], then this might
be a way to give meaning to a program that otherwise had no meaning.
If a strictly conformant program does include stdio.h, then this
pragma had better not change the meaning of the program.

>#pragma rename(strlen,Strlen)
IMHO #define Strlen strlen would be better for this.  Again it is hard
to see how a strictly conformant program could use this one.

>#pragma list(dumpmacros)
Also perfect.  Hmm, er... better than perfect.

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-implementing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?