5 ms·

Is there a reason you can't do printf("%.*s", strlen, strptr); ?

• jeffreygoesto 2y ago
  The terminating character is still the closing double quote and not a null, since the library does neither copy out nor alter the input. For example tiny_json replaces the closing quotes to create C strings, but that needs the full file to be in a mutable buffer which can be prohibitive for small controllers reading some config from flash only.
  • jdougan 2y ago
    With the "%.*s" format you need no null at the end. It just counts out the characters: #include <stdio.h> void main() { char buff[10] = {'R', 'o', 'b', 'o', 't', 't', 'y', 'p', 'e', 's'}; printf("=>%.*s<=", 4, ((char *)&buff + 3)); } prints =>otty<=
    • jeffreygoesto 2y ago
      Ah. Ok. Scanning the length before printing is mandatory then.
      • ska 2y ago
        You have to do (a variant of) one or the other, no?
      • jdougan 2y ago
        @msarnoff had already stipulated that the json lib is returning lengths: all the “tokens” are given as byte offsets and lengths
• msarnoff 2y ago
  Yes, that’s exactly what I’ve done.
  • jdougan 2y ago
    Any other issues with it? Sibling comments mentioned potential unicode issues.
    • msarnoff 2y ago
      I've only used it in an application where we ensure the data is ASCII-only. The only issue is that I've had to write a bunch of wrapper code around it (for looking up object properties by key, iterating over key/value pairs or array elements, etc.)
• deathanatos 2y ago
  A non-allocating library would be forced to return to you the unparsed string literal, since returning a parsed string can require an allocation. It might tell you that the literal is valid. E.g., take the JSON: "\"\uD83D\uDCA9\"" There's no (pointer, length) into that that you can then printf(…, ptr, len); you'd get the escapes, raw. Ofc., there might be situations like debugging where that's fine.