Possible bug with global char[]

Using Arduino IDE 1.x
1

Hi,

I am experiencing a weird bug with char[] declared in the global section. The code below does something odd where it appends the contents of the FSecond array to the end of FFirst, but FSecond remains fine. Is this something that is expected for C? (I'm a delphi guy) This seems like an odd bug to me.

Running on Arduino UNO SMD, IDE 0022

Code:

char FFirst[] = {20, 96, 21, 114, 22, 88, 23, 5}; 
char FSecond[] = {8, 160, 5,183 ,8 ,132 ,166, 5, 140 ,154 ,146};

void setup() 
{                
  Serial.begin(9600); 
  AnnounceEmail();
}

void loop() 
{

}

void AnnounceEmail()
{  
  Serial.println(FFirst);
  Serial.println(FSecond);
}
2

Strings are null terminated in C...

char FFirst[] = {20, 96, 21, 114, 22, 88, 23, 5, 0};
char FSecond[] = {8, 160, 5,183 ,8 ,132 ,166, 5, 140 ,154 ,146, 0};

They are also null terminated in Delphi but the compiler / run-time library makes it so you don't need to know that.

3

Thanks. I am well aware of the null terminated strings in Delphi, but this sort of thing should really be implemented in a compiler these days. Guess I should not assume.

4

Not if you tell the compiler is just a collection of characters instead of a string.

Rob

5

If I declare it as two separate variables then it should be treated as such. Do the same in MPLAB, Delphi, C# etc and it will give you the predicted behavior that is common, which is defined as a char array of the length it determines at compile time.

6

All C string funcs work on an array of characters with a \0 at the end. Print (FFirst) will start with the first character of FFirst and walk though memory until it sees a \0. In your case that was somewhere random after the end of FSecond. You were lucky it stopped when it did, it could have tried to print the entire contents of RAM :slight_smile:

You either have to manually put the \0 in as CB showed, or declare it as a string

char myString[] = "Hello";

or a pointer to a string

char *myString = "Hello";

You have control characters so that makes it harder. If they are standard escapable chars you can embed them in the string, if not doing what you're doing is probably the best way.

Remember C is only one step up from assembler, that's it's power, but you don't get as big a safety net as you may be used to.

Rob

7

Yeah I get your point. I'm pretty new to C and didn't think the functions work in this fashion, assuming the terminating char was implicit.

My chars are not standard escape chars, they are numbered commands for a chip it talks to serially. So this is the way I have to do things, however with this knowledge about how the functions work I can use it to my advantage when wanting to build the message to send to the chip.

Cheers.

8

If your chip could validly expect a null char, you shouldn't be passing a string, you should be passing a length and an array. Strings are human readable, commands to a chip are raw binary (at least that's my abstract take on such things).

9

MarkT:
If your chip could validly expect a null char, you shouldn't be passing a string, you should be passing a length and an array. Strings are human readable, commands to a chip are raw binary (at least that's my abstract take on such things).

yeah i only pass in the array. It uses the soft serial class and just calls the print function and passes the char array. However the strings are a useful tool to concat the char arrays together?