Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incremental parsing doesn't work with unquoted stuff when JSMN_STRICT is not defined #179

Open
mulle-nat opened this issue Dec 21, 2019 · 1 comment · May be fixed by #194 or #197
Open

Incremental parsing doesn't work with unquoted stuff when JSMN_STRICT is not defined #179

mulle-nat opened this issue Dec 21, 2019 · 1 comment · May be fixed by #194 or #197

Comments

@mulle-nat
Copy link

mulle-nat commented Dec 21, 2019

Here is a small program that shows the problem:

//#define JSMN_STRICT
#include "jsmn.h"
#include <stdio.h>
#include <string.h>

#define INCREMENTAL

static char  *json = "[\n"
"   1848,\n"
"   {\n"
"      \"key\": true\n"
"   }\n"
"]";


int   main( void)
{
   jsmn_parser   p;
   jsmntok_t     t[128];
   int           r;
   int           i;
   size_t        len;

   jsmn_init( &p);

   len = strlen( json);

#ifdef INCREMENTAL
   for( i = 1; i <= len; i++)
   {
      r = jsmn_parse(&p, json, i, t, 128);
      if( r < 0)
      {
         if( r == JSMN_ERROR_PART)
            continue;
         fprintf( stderr, "Failed to parse JSON: %d\n", r);
         return 1;
      }
      break;
   }
#else
   r = jsmn_parse( &p, json, len, t, 128);
   if( r < 0)
   {
      fprintf( stderr, "Failed to parse JSON: %d\n", r);
      return 1;
   }
#endif
   for( i = 0; i < r; i++)
      printf( "%.*s\n", t[ i].end - t[ i].start, &json[ t[ i].start]);
   return( 0);
}

This will see unquoted characters be turned into individual tokens:

[
   1848,
   {
      "key": true
   }
]
1
8
4
8
{
      "key": true
   }
key
t
r
u
e

The output for non-incremental or strict is correct:

[
   1848,
   {
      "key": true
   }
]
1848
{
      "key": true
   }
key
true

Obviously it's hard for the parser to detect the expected end for unquoted numbers. The solution could be to append to the previous token if it's a primitive and there has been no intervening space.

@pt300
Copy link
Collaborator

pt300 commented Mar 24, 2020

The problem here is mostly the way non-strict mode is. There is no definition of how it works and so it's difficult to say if behaviour is expected or not. Because of that, non-strict mode will be most likely dropped in a future release. In case it's still needed, a proper definition is required. You are welcome to give your input at #159.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants