Exception 207 On ARM Processor During Literal String Parsing

[79rpm]

I am reading from serial interface a literal string into a ARM micro-processor running Linux. The reason to use literal string is because I am storing the result of the UART reading into a std::string. A small string sample that I may enter over the serial is for example: "{"key1": true}" << written as: [quote][curly brace open][backslash][quote][key1][backslash][quote]...

When I display the string read from UART I get this via std::cout: {"key1": true} which is consistent with my input. Following that step I call parse on the string as follow:

json j_complete = json::parse(json_string); // with json_string holding "{"key1": true}"

If I run this code I hit exception 101 right on { complaining about the formatting not starting with ". This is inline with https://jsonlint.com/ if I paste the same Json string it is invalid. Now what I don't understand is why it is working no problem on x86 (MACOS). The library let me pass the string without " generating the object without exception. I am pre-designing code on x86 and porting back to ARM when my application is mature enough.

The next step I took is call parse on ARM platform with:

json j_complete = json::parse("""+json_string+""");

In that case I do not hit 101, so at least the input seems to be valid, but I hit another exception: 207 "cannot use key() for non-object iterators". Following the parsing I have code that retrieve the keys and value via the iterator but here again the ARM code does not work as expected compared to the x86 implementation.

What am I missing?

[79rpm]

The solution to this issue is to define a char (byte size) static array and load it with characters available in the std::string. I believe it is kind of a prerequisite to make it work properly . The library called rapidjson suffers the same issue basically. Also another issue I found inherent to dealing with UART is that the data crossing would consider backslash as a single character and not as an escape character. It shows up when we send [backslash][quote] which would correspond to ASCII 0x22 but comes up as [backslash]+[quote] . What I have noticed is that even when we take a std::string as an input we may still have [backslash]+[quote] as ASCII 0x92 + ASCII 0x22. Anyway all of this can be mitigated with a proper string analysis made by the library and a clean buffer generation underneath the call to parse() to avoid confusion. Right now I am cleaning up the std::string() making sure I start with '{' character and remove all the escape/backslash before storing it in a statically pre-allocated buffer.