The following code: fwsUniChar c; fwsUniChar *temp; temp=p->inPtr; c = *temp; temp++; p->inPtr = temp; correctly increments the pointer p by 0x01 instead of fwsUniChar c = p->inPtr++; which incorrectly increments the pointer p by 0x101 This code compiles and runs correctly with ANSI C compilers Also routine1() reentrant { enum ElementTagType type; routine2(&type); } routine2(enum ElementTagType *type) { type = START_TAG; } does not work (i.e. type in routine1 is not set to START_TAG after calling routine 2. There is a default XBPSTACK Any Ideas Thanks Barry
"The following code: fwsUniChar c; fwsUniChar *temp; temp=p->inPtr; c = *temp; temp++; p->inPtr = temp; correctly increments the pointer p by 0x01" You did not show us how p is declared. That aside, wouldn't that be incrementing the inPtr member of whatever p is pointing to, not p?. "instead of fwsUniChar c = p->inPtr++; which incorrectly increments the pointer p by 0x101" Again, see above. Also, are you certain that storing into c, the value of the inPtr member of whatever p is pointing to, is what you are trying to achieve here? If the inPtr member is a pointer, wouldn't you want:
fwsUniChar c; fwsUniChar *temp; temp=p->inPtr; c = *temp; temp++; p->inPtr = temp;
fwsUniChar c = p->inPtr++;
fwsUniChar c = *p->inPtr++;
Sorry another typo The originally incorrectly compiled code was enum RuleResult Produce_Digit(struct ParsingContext *p) { fwsUniChar c = *p->inPtr++; I believe the sytax is correct to fetch the charater and increment the pointer by 1 (not 0x101) and the structure is a lot smaller than 0x100. Any ideas why the code is incorrectly generated?
At the risk of asking the obvious, with whatever tool you are using to inspect the pointer, are you sure you are looking at the address part of the 3-byte generic pointer? I take it that you are using the large memory model, so your pointers are likely pointing to XDATA, which is identified by a memory type byte of 0x01 as part of the pointer. I guess the other way to present this, is to verify that the 3 bytes representing the pointer (assuming generic pointer p points to a byte at XDATA address zero) does not change from 0x01 0x00 0x00 to 0x01 0x00 0x01 like we'd expect (if you have not already done so).
Sorry, bad example use of the ubiquitous name p in this case, since your parameter is also named p. Using your specific example, you would look at the memory allocated to p->inPtr and verify that the 3-byte generic pointer inPtr member changed (or not) as I described.
I am using a MetaLink ICE for the DS80C400 to look at the pointers. I am using version 7.06a (the latest version of the compiler) large memory model and the pointer and contents are in XDATA. When I use the work-around the pointer changes from 0x01748f to 0x17490 and the program runs correctly. When I use the original code the pointer changes from 0x01748f to 0x17590 and the program fails. I inspected the characters addressed by the pointers as a sanity check. Barry
"When I use the original code the pointer changes from 0x01748f to 0x17590 and the program fails." You might try inspecting the assembly code/listing looking to see whether 257 is added to the pointer "all at once" or is spread out more (e.g., pointer incremented by one, then 256 added to it elsewhere). That might help point us in the right direction.