We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
In an inherited design where DATA is used to the hilt, I wanted to insert a 'general catcher' for debugging purposes in the process of doing so I got a puzzling data space overflow
void tryitcatch1(woid) { //UCHAR TTYCtemp; //TTYCtemp = 1; //BSIE_EA = DISABLE; //while (TTYCtemp); } ...... ...... for (toutctr = 60000 ; toutctr != 0 ; toutctr--) { if (j1708_pkt_incoming == FALSE) break; } if (toutctr == 0) { j1708_pkt_incoming = FALSE ; tryitcatch1(); // SEE BELOW }
with //tryitcatch1(); I get uncalled segment ...
with tryitcatch1(); I get data space overflow
I am puzzled
Erik
Erik,
This is miniscule, but did you copy-and-paste this code? If so, notice that the parameter for the function is actually "woid" and not "void." If, in fact, there's some parameter named "woid" that's being passed in memory rather than registers (?), then this could cause the problem. Alternatively, maybe the very presence of this misspelling and the lack of ANY more data space makes the compiler trigger this error rather an undeclared identifier, etc.
-Jay Daniel
THANKS,
as my mother said "the first place you go blind is on the eyes".
Thenks again, I typed this just after a conversation in German, stupid me.
PS what does C assume 'woid' is or is it an error that the declaration does not create an error/warning.
Once upon a time, there was this idea that any variable without a type would be assumed to be of type int - needed because of the KR calling style, where you didn't have function prototypes.
Your compiler is probably processing it as:
void tryitcatch1(int woid) { }
Per,
That's my best guess as well. What's puzzling me is this: Even assuming that's accurate, wouldn't that variable just be passed in registers anyway? Why would that cause a data space overflow?
I know my suggestion doesn't answer the reason for the strange error message. I don't have the C51 compiler, so I don't know what it thinks about K&R declarations. If it has a compiler switch for it, I would recommend to use that switch to deactivate all K&R support.
Without a function prototype, the compiler would not complain about the function call missing a parameter. Maybe unexpected K&R functions breaks up the internal compiler logic for handling all parameter passing, resulting in a changed allocation of global variables.
The workarounds for supporting C on '51 chips induces too much special cases that can't be found documented in the ANSI language standard. The assembler listings can show _what_ a compiler has done, but the _why_ can sometimes be hard to deduce. Sometimes even with the compiler source code available...