1

{"a" : 01} or {"a" : -000.1} is an invalid, but JQ is fine with it and interprets it as {"a" : 1} and {"a" : -0.1}.

Is it by design or a bug?

Jaro
  • 95
  • 1
  • 6
  • 1
    Indeed, according to [RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format](https://datatracker.ietf.org/doc/html/rfc7159), [Section 6](https://datatracker.ietf.org/doc/html/rfc7159#section-6) "A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. Leading zeros are not allowed.". So, I guess, strictly speaking, `jq` shouldn't accept that. – pmf Nov 20 '21 at 02:45
  • RFC 7159 9. Parsers "A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions." Same in rfc8259 – peak Nov 22 '21 at 22:51

1 Answers1

1

Since superfluous leading 0s are not allowed in JSON, a "strict mode" might be nice for jq, but without even invoking Postel's Law, it is evidently perfectly reasonable for a tool such as jq to accept them (JSON, after all, is supposed to be human-friendly), so long as the output that is supposed to be JSON is valid.

And besides, there are plenty of dour linters.

By the way, FWIW, NaN and Infinite are also accepted as input (and interpreted accordingly), so it's evident that jq's creators/maintainers intend there to be a "non-strict" mode when reading JSON texts.

For some background, see Why is JSON invalid if an integer begins with a leading zero?

One argument I've seen against allowing superfluous 0s is that since 00 is not valid JSON, a tool that purports to read streams of JSON should recognize 00 as two 0s. This is indeed the way that gojq's JSON parser handles leading 0s.

peak
  • 105,803
  • 17
  • 152
  • 177
  • Linters solve nothing. Let's assume I am going to create another JQ implementation. Should I deliberately accept leading zeros to be compliant with the original? An extra param like --strict would be nice IMO – Jaro Nov 20 '21 at 06:55
  • @Jaro - There is a another implementation of jq - gojq; it attempts to adhere to jq's advertised features that are clearly intended to be essential. There are quite a few intended differences, and it would not have surprised me if its author had chosen to make a strict mode the default, but: `gojq -n '000.1, 003, 2.0E001'` => 0.1 3 20 – peak Nov 20 '21 at 07:38
  • FWIW there's an open bug for the issue at https://github.com/stedolan/jq/issues/1404 for which the maintainer seems in favour of the idea of a fix but it's been a good few years without being addressed. – Weeble Nov 20 '21 at 23:19
  • 1
    Re "*a "strict mode" might be nice for jq*", A loose mode would be nicer :) [Comments, trailing commas, optional quotes around dict keys if identifier-like] – ikegami Nov 22 '21 at 17:35
  • @ikegami I fully second that. It should just accept JSON; --loose would be additional option – Jaro Nov 22 '21 at 20:27
  • @jaro - You might be pleased to know that gojq's JSON parser (as opposed to gojq's jq parser) handles 000 as a stream of three 0s. – peak Nov 29 '21 at 11:49