Byte array question
Don M
Posts: 1,652
Let's say that I have an array that is 23 bytes long defined in the CON section as:
CON
byte some_array_1[23]
and in the DAT section I have some data defined as:
DAT
some_array_2 byte $02,$00,$01,$05,$02,$00,$07,$01,$02,$05,$14,$14
The array in the CON section needs to be 23 bytes long as sometimes there may be some data that is 23 bytes long but not always.
If I wanted to preload the array from the DAT section to the array in the CON section I would use:
bytemove(@some_array_1, @some_array_2, 23)
But when I do this:
repeat idx from 0 to 23
term.hex(some_array_1[idx], 2)
I get data that is beyond the array from the DAT section because that is only 12 bytes long. I only use this 12 byte example because that is the length of some byte array that I might receive but I don't know that it is only 12 bytes long.
Is there a way to know how long a byte array is without looking for a 0 terminator because in this case there is no 0 at the end of the byte array in the DAT section it is some random data from memory I'm guessing.
If I wanted to preload the data into the longer byte array is there a better way than bytemove? Some way to pad the empty places with 0?
Comments
You don't define variables in the CON section, but in the VAR section.
No. Anyway, zero terminators are used for strings, not usually byte arrays in general, since zero could be a legitimate value.
If you're using a zero as the terminator, just add sufficient zero-padding to the DAT array.
-Phil
As Phil already stated, you probably mixed CON with VAR. A CON is a constant and actually only exists in your CON code unless you use it somewhere else in the code. If a constant is not used at all, you won't find it in the binary which the code is compiled to.
If you deal with dynamic binary data (where zero is a valid value) you would simply use a counter to keep track of the length of the received bytes. So, whenever you receive a byte you increase the counter. This also can be used to make sure that you do not try to store more received bytes than the size of your dat "variable" allows. Because the negative case of "I don't know the length of bytes I receive, it might be less" is "I don't know the length of bytes I receive, it might be more", which would result in overwriting stuff stored behind the DAT section. This can result in bugs you can spend days for finding ;o)
To be honest ... you should already have this kind of counter, otherwise, how do you address the array? Is it filled by some other COG? If so, the code in that COG should also write some length at the beginning.
Maybe you can tell us a bit more about the circumstances.
Yes. Sorry. It should have been VAR. Thanks for the explanation. I didn't think it could be done without a termination of some sort.