Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!ncr-sd!crash!pnet01!wade
From: wade@pnet01.cts.com (Wade Bickel)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Trouble with Images
Message-ID: <4256@crash.cts.com>
Date: 26 May 89 10:36:30 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 35

riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes:
>In article <May.23.14.52.22.1989.3122@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:
>>In article <1410019@hpcvca.CV.HP.COM> stan@hpcvca.CV.HP.COM (Stan Gibbs) writes:
>>>         USHORT chip imagepts[] ...
>
>>To be 100% ANSI conformant (that is, when ANSI gets officially adopted
>>and products can really be ANSI conformant) wouldn't they NOT be
>>allowed to add a keyword like "chip"?  Shouldn't it be "_chip" to
>>conform to the namespace requirements?  (venders can use all the
>>symbols that begin with "_")
>
>In a word, yes.  They actually support 2 versions, "chip" and "__chip".
>The "__" version is "intended to allow for an ANSI conforming program,
>while we offer the non-ANSI version for more readable code and some
>compatibility with MSDOS based products" (from the 5.0 User's Guide,
>quoted without permission).  In think they should not allow "chip", but at
>least they are aware of the issue, and most of their extensions do begin
>with "__".

        I think it was a good idea for Lattice to support "chip" as well as
"__chip".  After all, the routines which use it are Amiga specific and will
need conversion during a port anyway  It saves me #defining "__chip" to
"chi, to make my file more readable.  Just put the ofnding routines in
a seperate file and use conditional compilation flags to control it.


                                                        Thanks,


                                                                  Wade.


UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!wade
ARPA: crash!pnet01!wade@nosc.mil
INET: wade@pnet01.cts.com