A byte sized string problem, a long solution, but a quick question, too.

ElectricAye

I had this:

Var
{This variable helps verify that the entered SD card new file name is acceptable...}
Byte NameVerification

And I used that variable in pieces of code that looked something like this:

PUB Main

PressedKey := "X"
NameVerification := "X"
REPEAT Until ((PressedKey == CarriageReturn) AND (NameVerification == "N") )
    PressedKey := Keyboard.getkey {This picks up a keystroke if one occurs.}

And I got all kinds of insidious memory stomping problems, until I changed NameVerification from a BYTE to a LONG.

Var
{This variable helps verify that the entered SD card new file name is acceptable...}
LONG NameVerification

And that seems to solve the problem. So I'm guessing the reason my memory got stomped on is because strings need zero terminators, but if you restrict the variable to a BYTE, there's no room in them for the zero terminator, so things run amok.

Any chance that is the proper reasoning here?

Phil Pilgrim (PhiPi)

It must be something else. In Spin, "X" is not a string but a byte value; string("X") is a string and returns a word value.

-Phil

Duane Degn

I like to use a long to capture the return value of FullDuplexSerial (rxcheck). You need a long to hold a "-1" value.

This type of thing has bitten me more than once.

I'm not sure if this is your problem or not. It depends on what object you are using for "Keyboard."

I doubt the problem is a missing zero terminator.

Duane

ElectricAye

Phil Pilgrim (PhiPi) wrote: »

It must be something else. ...

Thanks, Phil. You, too, Duane. Two things about Props that always leave me tied in knots: string operations and memory stomping.

The keyboard object is this one:
http://obex.parallax.com/objects/56/

It might be something caused by the string objects I'm using, at least one of which warns of possible memory corruption.
http://obex.parallax.com/objects/529/
http://obex.parallax.com/objects/502/

I'm not sure how one goes about tracking down what memory is going where. Sounds like something pretty complicated. At least it's working for now, and it's just an optional part of what I'm doing anyway. It's just one of those puzzles that leaves me.... well, puzzled.

Thanks.

Duane Degn

You should probably post your code.

From what I see, declaring NameVerification a byte or a long shouldn't matter.

Strings are an array of bytes. Many of the string functions use a pointer to the location in memory where this array is held.

I'm guessing your problem was being caused by some other part of your code. It would be good idea to find the real problem.

I think you might have one of your dreaded memory stomping problems.

Duane

EmptyBit

Basically the same concept as the RS232 question you had posted. STOP processing this loop at a certain count or specified character condition has been met.


I believe the methods/processes of string comparison and conditional action such as performing *moves will corrupt memory if ever or up to the first null character it found outside the string. Only filling one byte of your defined long essentially gives the null character after that byte address by default. This long could still be manipulated as a 4 byte string/array/buffer as long as you stay within its declared size. It just won't play nice defined as a single byte in other objects with different intentions expecting conditions that do not exist.

A String does not need demarked with zero if the length is a known-fixed-constant. Although it offers more flexibility for working with variable string lengths. Carriage returns and/or line feeds could also be used if your method were looking for them instead of null. If the conditional statement never sees the significant marker, it can just keep on over writing memory without a clue. BTDT wrote my own fixed length methods to save room a highly developed string handler consumed.

25 years ago they called it null terminated strings. The Zero terminated term had me trying ascii "0" not ascii null or decimal zero as in Emptybyte! Duh(laughing at me-self), it's been a while since coding and it ain't as much like riding a bike as I expected. I can now claim I have forgotten more than I ever knew.

$0

ElectricAye

Duane Degn wrote: »

You should probably post your code.....
I think you might have one of your dreaded memory stomping problems.

....

Duane,

Funny thing is this: for purposes of posting here, I stripped my code down to what I thought were the bare essentials of what was causing the problem but then the problem went away. I tried finding the big hairy version of my code where I had first encountered the problem, but couldn't replicate the problem - so either I tweaked the original code and inadvertently helped things out or it was a Gremlin of some sort. No doubt it will bite me in the rear months from now when I least expect it, but I've got other fish to fry so I'm going to take my chances and just move on. I'm bad that way.

EmptyBit wrote: »

....

I believe the methods/processes of string comparison and conditional action such as performing *moves will corrupt memory if ever or up to the first null character it found outside the string. ...

String manipulations hurt my brain. Right now everything is working fine and I've now got a fully functioning spectrophotometer rescued from the garbage thanks to the wise men of the forum here helping me out with the RS232, etc., so I'm reluctant to dig into it to find out what went wrong earlier. I'm not a purist when it comes to this stuff, so I'm going to put string manipulations on my bucket list and hope I don't get bytten again. Wish me luck.

Thanks you guys!