Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!rutgers!ucsd!ucsdhub!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!shankar From: shankar@hpclisp.HP.COM (Shankar Unni) Newsgroups: comp.sys.hp Subject: Re: Array indexing problem (bug?) Message-ID: <1340095@hpclisp.HP.COM> Date: 2 Jan 90 21:10:50 GMT References: Organization: Hewlett-Packard Calif. Language Lab Lines: 28 > very clear on this matter. Its illegal.) The C compiler group is reluctant > to fix this problem because it would mean generating extra instructions > for every global array indexing operation. It's more than that: the construct given in the base note is very non-portable - for example, there is an excellent chance that this code will fail on Intel machines: after all, if the data is at the base of a segment, what happens when you compute an intermediate address that is outside the segment? Something could well be truncated, and you could end either crashing your program, or worse still, silently picking up garbage. It's best to avoid such constructs if you want to keep your programs portable between widely varying architectures. If this is automatically generated code (like a Pascal-to-C translator or something like that), then you can use Karl's suggested workaround (variations on that will work on most architectures) to insert some padding between the array base and the base of globals (and later go back and fix the translator :-). ----- Shankar Unni E-Mail: Hewlett-Packard California Language Lab. Internet: shankar@hpda.hp.com Phone : (408) 447-5797 UUCP: ...!hplabs!hpda!shankar DISCLAIMER: This response does not represent the official position of, or statement by, the Hewlett-Packard Company. The above data is provided for informational purposes only. It is supplied without warranty of any kind.