Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!maize.engin.umich.edu!milamber From: milamber@caen.engin.umich.edu (Daryl Cantrell) Newsgroups: comp.sys.amiga.programmer Subject: Re: Manx vs. SAS/Lattice Message-ID: <1991Apr20.052047.18815@engin.umich.edu> Date: 20 Apr 91 05:20:47 GMT References: <9104021420.AA10848@thunder.LakeheadU.Ca> <1991Apr19.193033.13587@visix.com> Sender: news@engin.umich.edu (CAEN Netnews) Organization: University of Michigan Engineering, Ann Arbor Lines: 33 In article <1991Apr19.193033.13587@visix.com> brett@visix.com writes: >In article , stephen@cia.docs.uu.se (Stephen Cooper) writes: >> Yet another bug in AztecC 5.0d: (YABIAC? :-) >> Compiling this: >> >> void >> DrawCurves (void) >> { >> SHORT xy[MAXPOINTS * 2]; >> struct Border BezierBorder = >> {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; [...] >Yes, for that. It looks like "xy" is declared in a procedure and is a local variable, >which means it will be allocated when you call the routine, from the stack. Now, you >then try to take the address of a item that will be on the stack. A no-no. You can >either make the "xy" array "static" so it will not be on the stack, or you could pull >it outside the DrawCurves() function and make it global (yech!). [...] Whoa, hold up there... Address-of is a perfectly legal operation on an auto- variable, it just isn't a valid initializer. Technically, the initializers for the Border structure must all be constants. In theory, since the struct- ure is reinitialized at every function entry, you could compute a new address for xy each time. BUT, it's not kosher C. I will say this: Manx should have pointed out the specific error, not "internal error". -- +---------------------------------------+----------------------------+ | // Daryl S. Cantrell | These opinions are | | |\\\ milamber@caen.engin.umich.edu | shared by all of // | | |// Evolution's over. We won. | Humanity. \X/ | +---------------------------------------+----------------------------+