Board index » cppbuilder » integer corruption?

integer corruption?


2006-06-30 10:32:31 PM
cppbuilder31
OK, I have now seen something very strange.
I found the behavior in the testing of a DLL
Given:
char* hmsf = "00:00:00:00";
int ErrorCode = 0;
int framesConv = 0;
AnsiString HMSF;
AnsiString sFrames;
Then in the code, I have this:
case 1: // Errors only
FramesToHmsf(frameCount, TCCounter.Fps, dfFlag,
hmsf, &ErrorCode);
HMSF = hmsf;
TCtoFrames(hmsf, &framesConv, &ErrorCode);
// in the following line, after assignment, the int framesConv
// has been corrupted!!!
sFrames = framesConv;
// now framesConv has been corrupted.
// in the following line, using sFrames.ToInt() compensates
// for the corruption of the int
if ((HMSF != frameHmsf)||(frameCount != sFrames.ToInt())) {
Line += " Error: got " + HMSF + " = " + sFrames + "!";
lbResultsLog->Items->Add(Line);
}
break;
If I write, instead:
sFrames = IntToStr(framesConv);
The variable is still corrupted. I have no idea why. Also, the string
sFrames contains the correct string equivalent of the integer -- before
corruption.
So later using sFrames.ToInt() gets me the actual value, at the expense
of some overhead.
What am I missing???
--
Bill
 
 

Re:integer corruption?

"William Meyer" < XXXX@XXXXX.COM >wrote:
Quote
OK, I have now seen something very strange.

I found the behavior in the testing of a DLL

Given:
SNIPPED
I notice that you are passing framseConv by address to TCtoFrames in the following line. Perhaps you have modified the value in the called function?
Quote

TCtoFrames(hmsf, &framesConv, &ErrorCode);
// in the following line, after assignment, the int framesConv
// has been corrupted!!!
sFrames = framesConv;
// now framesConv has been corrupted.
// in the following line, using sFrames.ToInt() compensates
// for the corruption of the int
if ((HMSF != frameHmsf)||(frameCount != sFrames.ToInt())) {
Line += " Error: got " + HMSF + " = " + sFrames + "!";
lbResultsLog->Items->Add(Line);
}
break;

If I write, instead:

sFrames = IntToStr(framesConv);

The variable is still corrupted. I have no idea why. Also, the string
sFrames contains the correct string equivalent of the integer -- before
corruption.

So later using sFrames.ToInt() gets me the actual value, at the expense
of some overhead.

What am I missing???

--

Bill
 

Re:integer corruption?

David Brenner wrote:
Quote
I notice that you are passing framseConv by address to TCtoFrames in
the following line. Perhaps you have modified the value in the called
function?
Yes, the function returns a value of interest. I then assign that value
to the string sFrames, and apparently, the assignment results in a
change to the integer variable. That's the problem I am trying to
understand.
--
Bill
 

{smallsort}

Re:integer corruption?

Couldn't it be that TCtoFrames corrupts the stack ?
--
Olivier Sannier
JVCL Coordinator
jvcl.sf.net/
Find more about me on LinkedIn:
https://www.linkedin.com/in/obones
 

Re:integer corruption?

"William Meyer" < XXXX@XXXXX.COM >wrote:
Quote
David Brenner wrote:

>I notice that you are passing framseConv by address to TCtoFrames in
>the following line. Perhaps you have modified the value in the called
>function?

Yes, the function returns a value of interest. I then assign that value
to the string sFrames, and apparently, the assignment results in a
change to the integer variable. That's the problem I am trying to
understand.

--

Bill
OK, I see now what you are saying. Sorry for the mixup.
 

Re:integer corruption?

David Brenner wrote:
Quote
OK, I see now what you are saying. Sorry for the mixup.
No problem. I could have, and probably should have, stripped things
down.
--
Bill
 

Re:integer corruption?

OBones wrote:
Quote
Couldn't it be that TCtoFrames corrupts the stack ?
It's not the call to TCtoFrames that is at fault. After that call, the
framesConv variable contains the right value. After:
sFrames = framesConv;
framesConv contains nonsense.
--
Bill
 

Re:integer corruption?

"William Meyer" < XXXX@XXXXX.COM >wrote:
Quote
char* hmsf = "00:00:00:00";
Do not do this!
The language allows this, to prevent the breaking of old pre-const code,
but you should be writing
char const* hmsf = "00:00:00:00";
instead. If you do, then the compiler can warn you if you're passing
this string to something that might modify it.
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2006 Discworld Convention <url:www.dwcon.org/>
 

Re:integer corruption?

Alan Bellingham wrote:
Quote
Do not do this!

The language allows this, to prevent the breaking of old pre-const
code, but you should be writing

char const* hmsf = "00:00:00:00";

instead. If you do, then the compiler can warn you if you're passing
this string to something that might modify it.
Ah, but in this case, I want the code to modify it.
--
Bill
 

Re:integer corruption?

"William Meyer" < XXXX@XXXXX.COM >wrote in message
Quote
Ah, but in this case, I want the code to modify it.
You are pointing to a string literal that is stored in the executable's
read-only memory. DO NOT try to modify it at all. If you are trying to
modify the string contents, then copy it to a local buffer first, and then
modify that instead. For example:
char hmsf[12];
strncpy(hmsf, "00:00:00:00", 12);
// modufy hmsf as needed ...
Gambit
 

Re:integer corruption?

Remy Lebeau (TeamB) wrote:
Quote
You are pointing to a string literal that is stored in the
executable's read-only memory. DO NOT try to modify it at all. If
you are trying to modify the string contents, then copy it to a local
buffer first, and then modify that instead. For example:

char hmsf[12];
strncpy(hmsf, "00:00:00:00", 12);
// modufy hmsf as needed ...
Unfortunately, your code does not work, while the form I used does.
--
Bill
 

Re:integer corruption?

"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote:
Quote
char hmsf[12];
strncpy(hmsf, "00:00:00:00", 12);
Or more easily
char hmsf[] = "00:00:00:00";
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2006 Discworld Convention <url:www.dwcon.org/>
 

Re:integer corruption?

William Meyer wrote:
Quote
Unfortunately, your code does not work, while the form I used does.
To be more specific, it breaks the functionality of my function, so
that's not a good thing!
--
Bill
 

Re:integer corruption?

"William Meyer" < XXXX@XXXXX.COM >wrote:
Quote
Ah, but in this case, I want the code to modify it.
Perhaps.
However, the word for what you are *actually* doing is corruption. You
are overwriting compile time constant data, and once you do that,
everything following is suspect.
Oh, look! This thread's title includes the very word 'corruption'.
My suggestion is as per my reply to Remy: 'char hmsf[] = "00:00:00:00";'
Alan Bellingham
--
Me <url:mailto: XXXX@XXXXX.COM ><url:www.doughnut.demon.co.uk/>
ACCU - C, C++ and Java programming <url:accu.org/>
The 2006 Discworld Convention <url:www.dwcon.org/>
 

Re:integer corruption?

Alan Bellingham wrote:
Quote
Perhaps.

However, the word for what you are actually doing is corruption. You
are overwriting compile time constant data, and once you do that,
everything following is suspect.

Oh, look! This thread's title includes the very word 'corruption'.

My suggestion is as per my reply to Remy: 'char hmsf[] =
"00:00:00:00";'
Thanks. It's nice to use a more correct declaration that does not break
the function.
OTOH, neither does it address my original concern, which was that the
code:
sFrames = framesConv;
Leaves framesConv corrupted. Nothing in the code was in any way
corrupting the content of hmsf.
To be clear, after making your change, my function is still performing
properly, but the curruption to framesConv is still happening.
--
Bill