rlittle@comix.cs.uoregon.edu (Robert A. Little) (01/04/91)
Q: Why does the following not work?
....
USHORT chip Image={0xF700,0xF700};
....
The SAS C5.10 compiler produces "Error 25: modifiable lvalue required"
If I remove the "chip" designation, the error does not occur...If I use
far/near/const etc. the error likewise does not occur... Why? Why should
chip cause the error... (BTW: this line was copied from the AmigaDOS
RK 1.3 manual)
Thanks...
rob
----------------------
rlittle@cs.uoregon.eduetxtomp@eos.ericsson.se (Tommy Petersson) (01/04/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: > > >Q: Why does the following not work? > >.... >USHORT chip Image={0xF700,0xF700}; >.... > >The SAS C5.10 compiler produces "Error 25: modifiable lvalue required" > >If I remove the "chip" designation, the error does not occur...If I use >far/near/const etc. the error likewise does not occur... Why? Why should >chip cause the error... (BTW: this line was copied from the AmigaDOS >RK 1.3 manual) > >Thanks... > >rob > >---------------------- >rlittle@cs.uoregon.edu I don't now if this will solve the problem, but try replace USHORT (which I beleive is obsolete) with UWORD. Tommy Petersson etxtomp@eos.ericsson.se
sie@fulcrum.bt.co.uk (Simon Raybould) (01/04/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: > > >Q: Why does the following not work? >USHORT chip Image={0xF700,0xF700}; I think you have to put the double underscore before it, I have certainly done it in the past without trouble. I.E. USHORT __chip Image={0xF700,0xF700}; Hope that works -- Simon J Raybould (sie@fulcrum.bt.co.uk) // {o.o} \X/AMIGA \-/ =========================================================================== British Telecom Fulcrum, Fordrough Lane, Birmingham, B9 5LD, ENGLAND.
johnl@SDFSUN1.hac.com (John Lee) (01/05/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: >Q: Why does the following not work? > >USHORT chip Image={0xF700,0xF700}; Shouldn't that be: USHORT chip Image[2] = {0xF700,0xF700}; since you're using two initializers? The SAS/C compiler's error message seems a little oblique--I think it's complaining that the second initializer can't be be assigned to anything. The "chip" keyword itself works fine (with or without the leading double underscores.) I've used it with no problems. ------------------------------------------------------------------------------- The crew faces deadly GURUs! Next time on AmigaDOS: The Next Generation. +--------+ John Lee | HUGHES | +--------+ ARPAnet: jhlee@hac2arpa.hac.com Hughes Aircraft Company The above opinions are those of the user and not of those of this machine.
d88-skl@dront.nada.kth.se (Stellan Klebom) (01/05/91)
In article <GHV^~Q#@uzi-9mm.fulcrum.bt.co.uk> sie@fulcrum.bt.co.uk (Simon Raybould) writes: > >USHORT __chip Image={0xF700,0xF700}; > Isn't it so that you cant initialize a short with a aggregate initializer? ;) I think that what was intended is the following: USHORT __chip Image[]={0xF700,0xF700}; Also, use UWORD instead of USHORT since USHORT is obsolete... Stellan
mmaston@portia.Stanford.EDU (Michael Maston) (01/05/91)
In article <GHV^~Q#@uzi-9mm.fulcrum.bt.co.uk> sie@fulcrum.bt.co.uk (Simon Raybould) writes: >In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: >> >> >>Q: Why does the following not work? >>USHORT chip Image={0xF700,0xF700}; > >I think you have to put the double underscore before it, I have certainly >done it in the past without trouble. > >I.E. > >USHORT __chip Image={0xF700,0xF700}; > >Hope that works > Actually you can say chip or __chip and the compiler will accept it. I believe the solution to the problem can be had by changing the line to the following (Worked for me!): USHORT chip Image[]={0xF700,0xF700); The error I got on the original program line was that a close bracket was expected. I have also read (in a recent Amigawhirled) that by selecting the option in the SAS options program to ALLOW chip/near/far keywords that it will actually DISALLOW their use. I do NOT have that box checked in my options and the compiler is allowing me to use the chip keyword so I assume this report is true. The person originating this question might check into that being the cause of his problem as well. Michael Maston GTE Government Systems Mt. View, CA 94043 "Gawd I LOVE my Amiga!" "MB bites it!"
rlittle@cs.uoregon.edu (Robert A. Little) (01/06/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: > > >Q: Why does the following not work? > >.... >USHORT chip Image={0xF700,0xF700}; >.... > >The SAS C5.10 compiler produces "Error 25: modifiable lvalue required" > > Two things...First: I mistyped the message--my code read: USHORT chip ImageData[]={0xF7000,0xEFFF,...}; Second: The compiler would only compile the code if I moved it from within a procedure to a global declaration...it compiles fine now...my only question is, Why? Why won't it compile if the declaration is made within a procedure? Some type of a scope problem? Thanks --rob rlittle@cs.uoregon.edu
f88ho@efd.lth.se (Hans Olsson) (01/06/91)
In article <1991Jan6.092515.6970@cs.uoregon.edu> rlittle@cs.uoregon.edu (Robert A. Little) writes: [..deleted] >Two things...First: I mistyped the message--my code read: > >USHORT chip ImageData[]={0xF7000,0xEFFF,...}; > >Second: >The compiler would only compile the code if I moved it from within a procedure >to a global declaration...it compiles fine now...my only question is, Why? >Why won't it compile if the declaration is made within a procedure? Some type >of a scope problem? > Things declared inside of procedures are normally allocated from the stack, so in order to make it work the compiler would have to do the following: Allocate memory upon entry of function. Free memory then you leave the function. And maintain a list of this memory so still could exit() from the function. This is a bit more than a pair of link/unlink. I don't see any reasons why it shouldn't work it you used static chip ImageData... inside a function ,but I don't have lattice so I can't test it. -- ---------- Hans Olsson Email: f88ho@efd.lth.se Snail: K[MN[RSV[GEN 8:118 222 45 Lund Sweden
BAXTER_A@wehi.dn.mu.oz (01/07/91)
> > I believe the solution to the problem can be had by changing the line to the > following (Worked for me!): > > USHORT chip Image[]={0xF700,0xF700); ^ ^ brace bracket Bet it didn't Regards Alan
mmaston@portia.Stanford.EDU (Michael Maston) (01/07/91)
In article <18471@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes: >> >> I believe the solution to the problem can be had by changing the line to the >> following (Worked for me!): >> >> USHORT chip Image[]={0xF700,0xF700); > ^ ^ > brace bracket > >Bet it didn't Ooops! Teach me not to cut and paste from the original source file for my examples....by the way, I call it a parentheses (whatever the single form of that is), not a bracket. I consider this -> [ <- a bracket... Picky, picky, picky! Speaking of 'C', anyone have a nice example of how to perform mutual exclusion on BOOLEAN gadgets? I have been wrestling with it, but for some reason it hasn't come out quite right! Pls excuse my ignorance in this matter! Danke! Michael Maston GTE Government Systems Mt. View, CA 94043
zlnem@marlin.jcu.edu.au (N Milward) (01/07/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: > > >Q: Why does the following not work? > >.... >USHORT chip Image={0xF700,0xF700}; >.... > >The SAS C5.10 compiler produces "Error 25: modifiable lvalue required" > >If I remove the "chip" designation, the error does not occur...If I use >far/near/const etc. the error likewise does not occur... Why? Why should >chip cause the error... (BTW: this line was copied from the AmigaDOS >RK 1.3 manual) > >Thanks... > >rob Image is a reserved word it probably should read ImageData. Image points to the actual image structure. This is defined in the include files. The Image structure points to the ImageData. Should read USHORT chip ImageData={..,..}; Hope this helps. Ross Milward.
rick@tmiuv0.uucp (01/08/91)
In article <1991Jan4.031246.20044@cs.uoregon.edu>, rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: > Q: Why does the following not work? > > .... > USHORT chip Image={0xF700,0xF700}; > .... > > The SAS C5.10 compiler produces "Error 25: modifiable lvalue required" > > If I remove the "chip" designation, the error does not occur...If I use > far/near/const etc. the error likewise does not occur... Why? Why should > chip cause the error... (BTW: this line was copied from the AmigaDOS > RK 1.3 manual) First of all, you've got two values inside the {} goodies. That means an array, so it would have to be Image[2]={0xF700,0xF700};. Also, I believe that the "chip" designator is "__chip" (two underscores). At least it is under 5.05 (which I'm still running). Taking all that into account, try: USHORT __chip Image[2]={0xF700,0xF700}; and see if that does the trick. > > Thanks... > > rob > > ---------------------- > rlittle@cs.uoregon.edu -- ---------------------------------------------------------------------------- [- O] Rick Stevens ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) "I'm tellin' ya, Valiant! Da whole ting stinks like yesterday's diapers!" - Baby Herman in "Who Framed Roger Rabbit" ----------------------------------------------------------------------------
rick@tmiuv0.uucp (01/08/91)
In article <1991Jan6.184905.29163@portia.Stanford.EDU>, mmaston@portia.Stanford.EDU (Michael Maston) writes: > In article <18471@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes: >>> USHORT chip Image[]={0xF700,0xF700); >> ^ ^ >> brace bracket >> >>Bet it didn't > > Ooops! Teach me not to cut and paste from the original source file for my > examples....by the way, I call it a parentheses (whatever the single form of > that is), not a bracket. > > I consider this -> [ <- a bracket... I can't resist!! { = left (open) curly brace } = right (closed) curly brace ( = left (open) parenthesis (plural: parentheses) ) = right (closed) parenthesis (plural: parentheses) [ = left (open) bracket ] = right (closed) bracket ^ = caret < = "less than" or "left caret" > = "greater than" or "right caret" Me = smart aleck! (heheheheheh!) 8-) = Smiley Face > Michael Maston > GTE Government Systems > Mt. View, CA 94043 -- ---------------------------------------------------------------------------- [- O] Rick Stevens ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) "I'm tellin' ya, Valiant! Da whole ting stinks like yesterday's diapers!" - Baby Herman in "Who Framed Roger Rabbit" ----------------------------------------------------------------------------
rick@tmiuv0.uucp (01/08/91)
In article <1991Jan6.092515.6970@cs.uoregon.edu>, rlittle@cs.uoregon.edu (Robert A. Little) writes: > In article <1991Jan4.031246.20044@cs.uoregon.edu> rlittle@comix.cs.uoregon.edu (Robert A. Little) writes: >> >> >>Q: Why does the following not work? >> >>.... >>USHORT chip Image={0xF700,0xF700}; >>.... >> >>The SAS C5.10 compiler produces "Error 25: modifiable lvalue required" >> >> > Two things...First: I mistyped the message--my code read: > > USHORT chip ImageData[]={0xF7000,0xEFFF,...}; > > Second: > The compiler would only compile the code if I moved it from within a procedure > to a global declaration...it compiles fine now...my only question is, Why? > Why won't it compile if the declaration is made within a procedure? Some type > of a scope problem? Well, sort of. The ANSI C specification (ANSI X3.159-1989) states in section 3.5.7, "Initialization", lines 34-35: "If the declaration of an identifier has block scope, and the identifier has external or internal linkage, the declaration shall have no initializer for the identifier." Now, in English, that means that a variable declared inside some program block (such as a function) CANNOT have an initializer value. The stuff inside your curly braces is an initializer. You can't have it both ways. Ah, well. > Thanks > > --rob > rlittle@cs.uoregon.edu I'm not sure you really appreciate that, but you're welcome. 8-) -- ---------------------------------------------------------------------------- [- O] Rick Stevens ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) "I'm tellin' ya, Valiant! Da whole ting stinks like yesterday's diapers!" - Baby Herman in "Who Framed Roger Rabbit" ----------------------------------------------------------------------------
johnl@SDFSUN1.hac.com (John Lee) (01/08/91)
In article <1991Jan6.092515.6970@cs.uoregon.edu> rlittle@cs.uoregon.edu (Robert A. Little) writes: >Two things...First: I mistyped the message--my code read: > >USHORT chip ImageData[]={0xF7000,0xEFFF,...}; > >Second: >The compiler would only compile the code if I moved it from within a procedure >to a global declaration...it compiles fine now...my only question is, Why? >Why won't it compile if the declaration is made within a procedure? Some type >of a scope problem? Aha! There's the rub... You cannot initialize aggregate automatic variables. You'll need to make it static by: 1) moving it outside the procedure, making it global, or 2) inserting the storage class keyword 'static' in front. I still think the SAS/C error message is oblique. I hate it when programs do that. ------------------------------------------------------------------------------- The crew faces deadly GURUs! Next time on AmigaDOS: The Next Generation. +--------+ John Lee | HUGHES | +--------+ ARPAnet: jhlee@hac2arpa.hac.com Hughes Aircraft Company The above opinions are those of the user and not of those of this machine.
bj@cbmvax.commodore.com (Brian Jackson) (01/08/91)
In article <12545@hacgate.UUCP> johnl@SDFSUN1.hac.com (John Lee) writes: >In article <1991Jan6.092515.6970@cs.uoregon.edu> rlittle@cs.uoregon.edu (Robert A. Little) writes: >>Two things...First: I mistyped the message--my code read: >> >>USHORT chip ImageData[]={0xF7000,0xEFFF,...}; >> >>Second: >>The compiler would only compile the code if I moved it from within a procedure >>to a global declaration...it compiles fine now...my only question is, Why? >>Why won't it compile if the declaration is made within a procedure? Some type >>of a scope problem? > >Aha! There's the rub... You cannot initialize aggregate automatic variables. >You'll need to make it static by: 1) moving it outside the procedure, making >it global, or 2) inserting the storage class keyword 'static' in front. ANSI C allows the initialization of aggregate auto variables as long as the initializers are constants (which these are.) See pages 85-86 and page 219 of the second edition K&R. Of course, the 'chip' keyword in SAS C makes this a bit unlikely, but the ANSI C compilers should accept it. The following compiles and runs just fine with Aztec 5.0d: main() { int foo[] = { 0,1,2,3 } ; int x ; for( x = 0 ; x < 4 ; x++ ) printf("x = %d\n", foo[x] ) ; } bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "Paradise is exactly like where you are right now, only better." | -----------------------------------------------------------------------
lrg7030@uxa.cso.uiuc.edu (Loren Rittle) (01/08/91)
johnl@SDFSUN1.hac.com (John Lee) writes: > Aha! There's the rub... You cannot initialize aggregate automatic variables. > You'll need to make it static by: 1) moving it outside the procedure, making > it global, or 2) inserting the storage class keyword 'static' in front. > > I still think the SAS/C error message is oblique. I hate it when programs do > that. No, that is not the rub :-). SAS/C v5.10 (and the past few before it) fully supports the initialization of aggregate automatic variables as per the ANSI standard. So, in other words, you don't know what you are talking about. The reason, as stated in other messages, is that the chip and the auto (implied in this case) keywords are incompatible with one another. If you know what an lvalue is the error message makes perfect sense, otherwise read pages 195-197 of K&R's second edition (Keep in mind that chip is a type qualifier). -- ``In short, this is the absolute coolest computer device ever invented!'' -Tom Denbo speaking about The VideoToaster by NewTek ``Think about NewTek's VideoToaster! Now think about the Amiga!'' Loren J. Rittle lrg7030@uxa.cso.uiuc.edu
Radagast@cup.portal.com (sullivan - segall) (01/08/91)
>> >> Second: >> The compiler would only compile the code if I moved it from within a procedu r >e >> to a global declaration...it compiles fine now...my only question is, Why? >> Why won't it compile if the declaration is made within a procedure? Some ty p >e >> of a scope problem? > >Well, sort of. The ANSI C specification (ANSI X3.159-1989) states in section >3.5.7, "Initialization", lines 34-35: > > "If the declaration of an identifier has block scope, and the identifier > has external or internal linkage, the declaration shall have no > initializer for the identifier." > >Now, in English, that means that a variable declared inside some program >block (such as a function) CANNOT have an initializer value. The stuff >inside your curly braces is an initializer. You can't have it both ways. > Yikes! I thought I knew what all of the departures were between Turbo-C and ANSI. One of my favourite expressions is: { struct soandso thisisit = { 1, 2, 3 }; } in lieu of: struct soandso_default = { 1, 2, 3 }; function() { struct soandso thisisit; Thisisit = soandso_default; } -Sullivan_-_Segall (a.k.a. Radagast) _______________________________________________________________ /V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that ' the electronic mail you are reading is genuine rather than someone's made up crap. _______________________________________________________________ Mail to: ...sun!portal!cup.portal.com!radagast or radagast@cup.portal.com } }
lrg7030@uxa.cso.uiuc.edu (Loren Rittle) (01/08/91)
Brian Jackson writes: > ANSI C allows the initialization of aggregate auto variables as long > as the initializers are constants (which these are.) See pages 85-86 > and page 219 of the second edition K&R. Of course, the 'chip' keyword > in SAS C makes this a bit unlikely, but the ANSI C compilers should > accept it. The following compiles and runs just fine with Aztec 5.0d: > > main() > { > int foo[] = { 0,1,2,3 } ; > int x ; > > for( x = 0 ; x < 4 ; x++ ) > printf("x = %d\n", foo[x] ) ; > } Well, I'm not sure if you are implying that SAS/C is less than ANSI C or not, but it sure sounds like it to me, so I feel I must defend it, without slamming the other guy as you decided you had to. First off, the above code compiles and runs just fine under SAS/C also. With the strict ANSI switch (-ca) turned on, SAS will disallow the chip (and other Amiga extension) keywords, but will still allow the __chip, __far, etc. versions of these keywords as allowed under ANSI. Of course, the reason void main(void) { short __chip ImageData[] = {0xffff, 0x0000, 0xffff, 0x0000}; <insert your code here!> } is flagged as an error is that you have no idea during compile time whether the stack will be located in CHIP RAM or not (Let's hope not!). To futher explain, we know auto variables *must* go on the stack and we know that things specified as __chip items *must* go in CHIP RAM. The compiler sees at compile time that these two conditions can most likely not be satisfied at run time and *must* flag it as an error. OK, I will take one quick poke at Manx, do you guys using Manx really have to suffer without a __chip keyword? ATOM and putting chip data in separate source files (and using special compiler switches) went out of vogue years ago :-). OK, how many of you really even know what ATOM is? (I guess all the Aztec guys... :-) Send mail and I will summarize. Loren J. Rittle -- ``In short, this is the absolute coolest computer device ever invented!'' -Tom Denbo speaking about The VideoToaster by NewTek ``Think about NewTek's VideoToaster! Now think about the Amiga!'' Loren J. Rittle lrg7030@uxa.cso.uiuc.edu
markv@kuhub.cc.ukans.edu (01/09/91)
>>> >>>I believe the solution to the problem can be had by changing the line to the >>> following (Worked for me!): >>> >>> USHORT chip Image[]={0xF700,0xF700); >> ^ ^ >> brace bracket >> >>Bet it didn't Several points. One, chip and aligned keywords must be on static data, not "auto" data. If you declare such data in a function it is an error, but if you prefix with with "static", ie: void foo() { static USHORT chip Image[]=... } Second, "Image" is a standard Amiga structure tag. While Okay, I find its a bad idea to have multiple instances of the same name that are different things. (Intuition.h, struct Image Image, pretty confusing...). > I consider this -> [ <- a bracket... Correct. []'s are brackets, ()'s are parenthesis, and {} are braces. Look in any current English guide. > Picky, picky, picky! > >Speaking of 'C', anyone have a nice example of how to perform mutual exclusion > on BOOLEAN gadgets? I have been wrestling with it, but for some reason it > hasn't come out quite right! The AmigaMail volume for 1990 has a good article. In general... You must handle exclusion yourself, because it is unimplemented. If you do this in general, mutual exclude gadgets should be TOGGLESELECT, BOOLEAN, and GADIMMEDIATE. GADHBOX should not be used. You also must twiddle the gadgets in a way friendly to Intuition. In general, get a gadget message, check the exclusion, and twiddle the SELECTED bit and refresh the gadgets. > Pls excuse my ignorance in this matter! Nolo probleme, > Danke! > > Michael Maston > GTE Government Systems > Mt. View, CA 94043 Pahzhalsta, -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bj@cbmvax.commodore.com (Brian Jackson) (01/09/91)
In article <1991Jan8.081022.21160@ux1.cso.uiuc.edu> lrg7030@uxa.cso.uiuc.edu (Loren Rittle) writes: >Brian Jackson writes: >> ANSI C allows the initialization of aggregate auto variables as long >> as the initializers are constants (which these are.) See pages 85-86 >> and page 219 of the second edition K&R. Of course, the 'chip' keyword >> in SAS C makes this a bit unlikely, but the ANSI C compilers should >> accept it. The following compiles and runs just fine with Aztec 5.0d: >> >> main() >> { >> int foo[] = { 0,1,2,3 } ; >> int x ; >> >> for( x = 0 ; x < 4 ; x++ ) >> printf("x = %d\n", foo[x] ) ; >> } >Well, I'm not sure if you are implying that SAS/C is less than ANSI C >or not, but it sure sounds like it to me, so I feel I must defend it, >without slamming the other guy as you decided you had to. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So, being "not sure", you took your thoroughly erroneous assumption and ran with it, slamming me instead? Try harder to (1) not be defensive about your favorite compiler, and (2) not put words in other people's mouths. I posted that example in Manx because that's what I had handy at the moment. I use (and like) both compilers and I wasn't "slamming" anything. The number of people on here with poor ego formation is always surprising to me. "My computer is better than your computer." "My compiler is better than your compiler." "My cola is better than your cola." Give the world a break. My statement: "The following compiles and runs just fine with Aztec 5.0d:" This constitutes "slamming" SAS ?? Sheesh++ >First off, the above code compiles and runs just fine under SAS/C also. >With the strict ANSI switch (-ca) turned on, SAS will disallow the >chip (and other Amiga extension) keywords, but will still allow the >__chip, __far, etc. versions of these keywords as allowed under ANSI. >Of course, the reason >void main(void) >{ > short __chip ImageData[] = {0xffff, 0x0000, 0xffff, 0x0000}; > <insert your code here!> >} >is flagged as an error is that you have no idea during compile time >whether the stack will be located in CHIP RAM or not (Let's hope not!). >To futher explain, we know auto variables *must* go on the stack and we >know that things specified as __chip items *must* go in CHIP RAM. The >compiler sees at compile time that these two conditions can most likely >not be satisfied at run time and *must* flag it as an error. No kidding. That's what I said: "Of course, the 'chip' keyword in SAS C makes this a bit unlikely,..." Translation: The use of the chip keyword in an auto variable creates certain fairly obvious problems. That better? >OK, I will take one quick poke at Manx, do you guys using Manx really >have to suffer without a __chip keyword? ATOM and putting chip data >in separate source files (and using special compiler switches) went out >of vogue years ago :-). OK, how many of you really even know what >ATOM is? (I guess all the Aztec guys... :-) Send mail and I will >summarize. "Us guys using Manx" are probably smarter that you think. But it's nice to know that we have a mature and informed person we can turn to when we get lost in this great, big scary world. I have managed for years to get along without the 'chip' keyword. I certainly haven't "suffered". It's nice but certainly not required. Yes, I know what ATOM is and I manage to get along just fine without it. bj >Loren J. Rittle ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEmie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | |---------------------------------------------------------------------| | It requires a very unusual mind to undertake the analysis of | | the obvious." | -----------------------------------------------------------------------