Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!rutgers!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga
Subject: Re: #pragma PREPROCESSOR control is evil!
Keywords: #pragma spam tuna armadillo piano
Message-ID: <1410@sas.UUCP>
Date: 2 Jan 90 15:36:21 GMT
References: <10415@etana.tut.fi> <9532@microsoft.UUCP> <411@enuxha.eas.asu.edu> <6@microsoft.UUCP> <25206@cup.portal.com> <10033@microsoft.UUCP>
Reply-To: walker@sas.UUCP (Doug Walker)
Distribution: na
Organization: SAS Institute Inc, Cary NC
Lines: 67

In article <10033@microsoft.UUCP> w-stephm@microsoft.UUCP (Stephan Mueller) writes:
>Doug Walker writes:
>% #pragma is extremely non-portable.  Each compiler can implement any #pragma
>% keyword any way they wish, and you cannot #define a #pragma away.  You can
>% get rid of __chip simply by defining it to nothing.
>
>There is no need to #define a #pragma away.  K&R 2nd edition, section A12.8
>pp 233:
>
>"A control line of the form
>    #pragma token-sequence(opt)
>causes the processor to perform an implementation-dependent action.  An
>unrecognized pragma is ignored."

I am heartily tired of this discussion, since it is (apparently) a case of 
religious belief, but for the benefit of those who didn't seem to get
the point the first time,

#pragma FOOBAR bletch blah bwap

may be implemented on compiler A to mean 'turn on the global optimizer',
while on compiler B the EXACT SAME LINE may mean 'delete all the files on 
my hard disk when I compile this file'.  This is 100% completely ANSI 
conforming definition on BOTH compilers, but the user of compiler A will
be horrified when running compiler B on the file.  This is of course
an extreme example, but it illustrates the fact that #pragmas are NOT
portable.  There is no provision specified to allow a compiler to
determine whether or not the #pragma applies to it.

This is what I meant when I said:
>% There is no portable way to define a non-portable feature.
>


>If I want to port to another Amiga compiler, say Manx, or Amix or some
>cross-compiler generating Amiga code, then __chip will be non-portable
>but the code using it will not.  In this case, the behaviour of #pragma
>is preferable.  Those compilers that do not support the #pragma will
>still be able to compile the code, and one will need to specify a link
>option or something to get the appropriate module into chip RAM.

There is no difference between a couple of lines of #pragmas in an
include file somewhere and a couple of lines of #defines to get rid
of the new keywords.  I'm sorry, I do not believe this is any more
of a kludge than the #pragmas, and I DO believe it is easier to 
maintain since you SEE the __chip keyword on the chip items, and
if you change the name of the item the __chip keyword applies
automatically to the new one.


One other problem: How do you limit the SCOPE of the #pragma?  Or 
are you saying that one

#pragma chip foobar

at the top of the program makes all variables named foobar, including
extern, static and automatic, go into chip memory?  How do you declare
an automatic pointer to chip memory?  How do you declare a near pointer
to far memory, or a far pointer to chip memory?  


  *****
=*|_o_o|\\=====Doug Walker, Software Distiller=======================
 *|. o.| ||
  | o  |//     "READY!   FIRE!   AIM!   (Software under development!)
  ======
usenet: ...mcnc!rti!sas!walker   plink: dwalker  bix: djwalker