Pages: 1 [2]   Go Down
Author Topic: strange array corruption  (Read 2531 times)
0 Members and 1 Guest are viewing this topic.
Global Moderator
Offline Offline
Brattain Member
*****
Karma: 474
Posts: 18696
Lua rocks!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I assume this sort of corruption can’t occur from the normal string manipulation commands (ie strcat() and strcpy() ) because even if you do attempt to move/copy a 20 element array into a 10 element array, then the corruption has to be linear – by this I mean the first 10 elements will be handled correctly, and the next 10 memory locations will be corrupted in order. Is this right?

In principle, yes.

But my point was that the corruption is not necessarily caused by string manipulation commands. Any assignment to an array, particularly one that goes out of bounds, could cause it. The very fact that a single byte (well, two separate single bytes) seem to have been corrupted suggests it isn't a string manipulation (which generally would affect at least two bytes, if you include the terminating 0x00 byte), but rather an assignment to a char or byte array, or something similar.
Logged

UK
Offline Offline
Jr. Member
**
Karma: 2
Posts: 90
It was like it when I found it
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

thanks Rob, I think you're miss-quoting. expected_resp_string is actually ">" and the result is...
Quote
WaitResp. Expected <>>
that also explains the extra ">".

My application is in a state of flux, info has moved, and I'm no longer using clean_buff - but the corruption is still the same. It's nice to know there's some things you can rely on!

Any thoughts on wether I should be using char or byte arrays as per my last post?

Regards
Logged

nr Bundaberg, Australia
Online Online
Tesla Member
***
Karma: 126
Posts: 8472
Scattered showers my arse -- Noah, 2348BC.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

OK, it's not obvious from the code we've seen why expected_resp_string is ">", and on the surface that doesn't make a lot of sense, but if it is it is smiley

______
Rob
 
Logged

Rob Gray aka the GRAYnomad www.robgray.com

UK
Offline Offline
Jr. Member
**
Karma: 2
Posts: 90
It was like it when I found it
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The ">" is basically the 'cursor' - it's the response back from the SMS module that you expect to see to indicate the previous command was processed. Sorry, should have made it clearer.
Logged

Seattle, WA USA
Offline Offline
Brattain Member
*****
Karma: 601
Posts: 48543
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Any thoughts on wether I should be using char or byte arrays as per my last post?
Signed char arrays (the default type, if you don't specify unsigned) hold values in the range -128 to 127. What purpose a -54 serves is beyond me. All the characters in the english language have ASCII values between 0 and 127, so signed char is fine for holding them. For other languages, the values between 128 and 255 ARE used, so the array type needs to change to byte or unsigned char.

The reason that the string functions don't care whether you use char or byte is because the values of interest in the arrays are all 8 bit values, and all positive. That the form of one type limits the positive values it can hold to no higher than 127 is of no concern to the string functions.
Logged

Ontario
Offline Offline
God Member
*****
Karma: 24
Posts: 860
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The reason that the string functions don't care whether you use char or byte is because the values of interest in the arrays are all 8 bit values, and all positive.

This is, of course, total hogwash.  The strxxx() functions work with any 8-bit values, the only magic value being '\0', and it is possible, even for English text to use characters like £ © º ¼.  The fact that characters in Ardiuno are 8-bit limits us to 8-bit character encodings, like ISO-8859-x, but in no way limits us to English much less ASCII text.
Logged

Pages: 1 [2]   Go Up
Jump to: