parser: fix double-free in example snippet

See merge request !59

Deprecate signals on JsonParser

See merge request !69

Signals have always been the wrong mechanism to handle injection and
validation of JSON data inside the parser. Validation should happen on
the whole JSON tree *after* the parser has completed its run.

If you want to influence how the JSON data is parsed, you get to
subclass JsonParser and override its virtual functions.

Do not emit signals or call virtual functions if there is nothing on the
other side catching those emissions.

Wrap g_signal_emit() with our own type safe functions.

Ebassi/doc fixes

See merge request !68

Add JsonParser:strict

Closes #15

See merge request !67

Identifiers in JSON can only be lowercase.

This way command line tools can rely on strict JSON validation.

Instead of parsing the sign separately inside JsonParser.

The JSON spec mandates that there can't be no whitespace between the sign
and a number, but we skip whitespace inside JsonScanner to avoid having
to parse it everywhere.

Conformance tests updated:

- n_number_minus_space_1.json

If the strict parsing bit is enabled:

- JsonScanner will reject comments
- JsonParser will reject multiple object and array definitions as top
  level elements
- JsonParser will reject leading space and empty JSON data

Conformance tests:

- n_object_trailing_comment.json
- n_object_trailing_comment_slash_open.json
- n_single_space.json
- n_structure_double_array.json
- n_structure_no_data.json
- n_structure_object_with_comment.json
- n_structure_UTF8_BOM_no_data.json

A property to toggle strict conformance to the JSON spec, disabled by
default to ensure backward compatibility.

Andy Holmes authored May 22, 2023 and Andy Holmes committed Mar 17, 2024

The `json_parser_get_root()` method is annotated `(transfer none)`, but
the example uses an auto-cleanup that results in a double-free.

Remove `g_autoptr()` from the `JsonNode` variable in the example for
`JsonParser`, to fix the snippet and prevent any confusion.

Update json-value.c

Closes #71

See merge request !66

Richard Barnes authored Mar 04, 2024 and Emmanuele Bassi committed Mar 17, 2024

Fixes a `-Wshift-sign-overflow` warning

Closes: #71



Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>

Replace an assertion with an error

Closes #10

See merge request !65

We need to be able to catch malformed Unicode from JsonParser; using a
strong assertion inside JsonScanner makes that impossible.

Fixes: #10

Improve conformance of the JSON tokenizer and parser

See merge request !63

Most of the invalid tests marked as "xpass" do so because of long
established features on JSON-GLib. Making them fail as expected would
require breaking backward compatibility.

Leaving a comment to explain the reason why these tests are allowed to
pass avoids breakages in the future.

Commenting tests that are expected to pass/fail is useful for future
reference.

These control characters:

- \n
- \t
- \r
- \f
- \b

Are not allowed inside strings unless escaped.

Conformance tests:

- n_string_unescaped_newline.json
- n_string_unescaped_tab.json

JSON only allows the following escaped characters:

- \"
- \\
- \/
- \b
- \f
- \n
- \t
- \u

Additionally, \u only allows 4 hex digits after it.

If the Unicode character is a half of a surrogate pair, only another
\uXXXX sequence is allowed to follow.

The following conformance tests now pass:

- i_string_incomplete_surrogate_and_escape_valid.json
- i_string_incomplete_surrogate_pair.json
- i_string_invalid_surrogate.json
- n_string_escape_x.json
- n_string_escaped_ctrl_char_tab.json
- n_string_escaped_emoji.json
- n_string_invalid_backslash_esc.json
- n_string_invalid_unicode_escape.json
- n_string_unicode_CapitalU.json

Use the JSON conformance tests from: https://github.com/nst/JSONTestSuite

The suite is split into three:

- implementation-defined, which may pass or fail
- valid, which should pass
- invalid, which should fail

We're currently experiencing some unexpected passes in the invalid
tests, mainly due to the fact that JsonScanner is lenient for some
functionality, like BOM and comments.

We are far too lenient with numbers:

- leading zeros are invalid
- leading and trailing periods are invalid

In JSON, numbers with a fractional part cannot start with '.' as a
shorthand for '0.'.

There's no hex, binary, or octal notation in JSON.

Drop the use of GLib types, so we can unify the token types and drop any
pretense of extendability.

We don't use it outside the JsonScanner implementation.

There's only one scope.

We don't need to generate the error message inside JsonParser: the
tokenizer has all the information already.

JsonScanner is not a generic tokenizer any more, so we don't need a
scoped, extensible symbol lookup table for barewords.

Let's save some memory and reduce some complexity.

There's no point in doing it inside JsonParser.

Sadly, we need to keep a copy of the tokens in JsonParser for error
handling.