Curly Braces in strings or quotes { }

Ran accross a bug in the IDE when trying to parse some JSON data. Turned out it wasn't a problem with my code but the way the IDE (1.0.5) interprets Curly Braces.

Says -

At present this feature is slightly buggy as the IDE will often find (incorrectly) a brace in text that has been "commented out."

The IDE not only finds them "commented out" it also finds them embedded in constant char arrays, Serial.print statements, ect.
This was my offending statement -
if (strstr(clientBuf, "{"") != 0)
After figuring out that this was my problem statement I thought I had to escape the curly brace with a back slash or a double curly brace. After a couple of hours of screwing around with this I finally figured out that my code compiled and ran fine, it was only the IDE making me think I had a problem.

For instance the following code compiles and runs correctly but when you click around in the IDE and try to verify that you've got your braces balanced it looks like your code is screwed up -

void setup() {
  Serial.begin(9600);
}
void loop() {
  Serial.println("A Curly Brace {");
  while(true){} //Forever
}

I've found that you can get your Curly Braces to balance out by adding another one in a comment such as in this code.

void setup() {
  Serial.begin(9600);
}
void loop() {
  Serial.println("A Curly Brace {");
  //}
  while(true){} //Forever
}

Code like this is fine because the 2 Curly Braces in the print statement balance out.

void setup() {
  Serial.begin(9600);
}
void loop() {
  Serial.println("2 Curly Braces {something in here}");
  while(true){} //Forever
}

Seems that 1.5.4 has it too - think the underlying algorithm is (too) simple
CTRL-T is your friend :wink:

robtillaart:
think the underlying algorithm is (too) simple

I don't think I would have put it that politely!

writing good language parsers/interpreters is not trivial as you must keep quite some state. a string like print(" use " instead of { "); implies you need to be able to parse string-mode including escapes which can be part of a #define etc.

So as long I have not written a better one I have to "count the blessing" of the current one :slight_smile:

SInce this presumably happens before the C preprocessor gets to it, you might be able to use a trigraph:

robtillaart:
So as long I have not written a better one I have to "count the blessing" of the current one :slight_smile:

Knowing how hard it is to do correctly, I wouldn't piff about trying to write my own parser unless I knew I was competent to do it correctly - and even then I probably wouldn't write my own, I'd use somebody elses. Having got this far down the hole, the author surely knows enough to stop digging. But no, maybe just one more shovel will do the trick.

written several parsers (for different projects) but the better ones were
0) based upon usage scenarios

  1. resulting in extended requirements,
  2. resulting in test driven development (big test set that covered the requirements, including explicitly failing ones)

I have written parsers, including an expression parser for a Photoshop filter factory clone which used lex and yacc.

The real hard part is error detection, reporting and recovery.

sigh, good old lex & yacc :slight_smile: