Implication of assign a value at function entry
-
I made a DATA breakpoint in Visual Studio and the overlay was some where deep in Windows in ntdll I did a Call Stack and it wasn't in the function that BASSM was declared truth is at the very least since the value of BASSM is not being changed I should qualify it with a const to save compiler the trouble of initializing it every time
-
I made a DATA breakpoint in Visual Studio and the overlay was some where deep in Windows in ntdll I did a Call Stack and it wasn't in the function that BASSM was declared truth is at the very least since the value of BASSM is not being changed I should qualify it with a const to save compiler the trouble of initializing it every time
No, you should first find out where it is being overwritten and why. This error tells you that you have a bug in your code, so rather than try to hide it, you need to fix it. But without seeing more of your code it is difficult to guess what might be the cause.
-
No, you should first find out where it is being overwritten and why. This error tells you that you have a bug in your code, so rather than try to hide it, you need to fix it. But without seeing more of your code it is difficult to guess what might be the cause.
-
I could post all the code in the function but I don't think that would help I'll spend tonite trying to figure it and regardless I'll re-declare BASSM as const that still shouldn't stop the bug as its still a local stack variable thanks
-
ForNow wrote:
I'll re-declare BASSM as const
Well, good luck, but you still have a bug in your code.
-
I’ll post it tommorow if I don’t get anywhere it is not clearly apperent as I never move anything into BASSM Thanks
For clarification the value of BASSM is different at the end of the process_trace() method, than the initialized value?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
For clarification the value of BASSM is different at the end of the process_trace() method, than the initialized value?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
the first byte of the BASSM X'0C' gets overlayed not sure where I am going to have to step thru process_trace and check BASSM intermittently Thanks
If it get overwritten consistently, stepping through the method is the way to go.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
the first byte of the BASSM X'0C' gets overlayed not sure where I am going to have to step thru process_trace and check BASSM intermittently Thanks
-
Set a watchpoint on it in the debugger: Watch and QuickWatch Windows[^]
-
Hi I am getting a local variable overlayed now I am beginning to think it maybe because of the way I declared it for example void process_trace() { char BASSM[2] = {0X0C, 0XEF}; This is still considered a local variable even though its assigned value since I didn't use the key word static So I guess on entry to the function the complier re-initializes the value everytime I guess I am thinking since this variable is some how being overlayed and I am not changing the value I should make it static Thanks
I'm not sure what the others are thinking, but context is important here. You have defined BASSM within process_trace. Once you get to the bottom of process_trace (that little curly brace you step over), that context is lost. From a code point of view, it no longer exists. From a memory point of view, it BASSM may reference memory that still contains the values you init'd it too, but you cannot depend on that. Context is key here.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
I'm not sure what the others are thinking, but context is important here. You have defined BASSM within process_trace. Once you get to the bottom of process_trace (that little curly brace you step over), that context is lost. From a code point of view, it no longer exists. From a memory point of view, it BASSM may reference memory that still contains the values you init'd it too, but you cannot depend on that. Context is key here.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
ForNow wrote:
I'll re-declare BASSM as const
Well, good luck, but you still have a bug in your code.
There was a VFETCH macro which basically copied over data from the Mainframe emulated storage to your program the macro had a length however it would append a NULL (CString Style) at the end so even though I specified 4 bytes it put a null at the 5 th byte The local storage the way it is laid out by the compiler is not the way it’s declared in the function so even though the area the VFETCH macro was using wasn’t declared after the BASSM the compiler laid it out that way and the VFETCH overlaid the 1st byte of BASSM I fixed this problem but I also moved the BASSM to global storage by making it static Thanks for all the help
-
There was a VFETCH macro which basically copied over data from the Mainframe emulated storage to your program the macro had a length however it would append a NULL (CString Style) at the end so even though I specified 4 bytes it put a null at the 5 th byte The local storage the way it is laid out by the compiler is not the way it’s declared in the function so even though the area the VFETCH macro was using wasn’t declared after the BASSM the compiler laid it out that way and the VFETCH overlaid the 1st byte of BASSM I fixed this problem but I also moved the BASSM to global storage by making it static Thanks for all the help
