[clojure.edn] Leading zeros in numbers

Question

clojure.edn allow leading zeros ending up reading such number as octal representation. The problem is that it is also allowed to have indefinite amount of leading zeros for octals:

000000000000042  ;; => 34

and when there is a suffix "M" that forces floating point representation the same string become float 42 stripping all leading zeros.

000000000000042M ;; => 42M

At the same time EDN specification forbids integers with leading zeros at all even for floats.
I found a ticket about leading zeros in data.json but I think it should be expanded to cover clojure as well.

In the same scope but origin is in the EDN spec:
float specification allows leading zeroes in exponent and only zeros in fractional parts:

0.00000000...00
0.0e0001

probably because of that clojure.edn read such numbers without error too.

Comments

How can it be caught at the border via validation without actually parsing the number? And if the parsing is done during validation, then an all-zero number can also be validated just fine, without any changes to `clojure.edn`.

But it feels like bike shedding at this point, to be honest. Even if you disallow all such integers, you still don't really improve the situation w.r.t. DoS because leading zeros are explicitly allowed in the `exp` part of floating point numbers.

---

Didn't I mention exponent part in the original post? :)

> How can it be caught at the border via validation without actually parsing the number?

You can detect leading zeros during parsing -> throw exception without finishing the number because leading zeroes are forbidden. Saying this with a confidence because I recently finished such thing.

> But it feels like bike shedding at this point, to be honest.

I would like to know someone else opinion on this topic :) My thoughts are all there.

---

> Didn't I mention exponent part in the original post? :)

I'm not saying that you missed something. My point is that regardless of what you do to integer parsing, floating point parsing already enables DoS, and it cannot be changed unless the format spec is made stricter, which is a breaking change.

---

what else can I say -

---

Somehow my thumbsup is invisible :)

To be clear: the primary issue is that 042 and 042M handle leading zeros differently. That's inconsistent regardless of DoS concerns. Is there a rationale for this difference, or is it an implementation artifact?

Answer 1

Leading zeroes in Clojure should largely follow the lead of Java when the reference is unclear:

• Long - multiple leading 0s allowed, treated as octal
• BigInteger - multiple leading 0s allowed, treated as decimal in Java BigInteger, octal in Clojure (this is a difference, but supported by the reader reference page)
• Double - multiple leading 0s allowed in either whole number part of exponent, treated as decimal
• BigDecimal - multiple leading 0s allowed, treated as decimal

With respect to edn, there are additional constraints - octal is not supported, and leading 0s not allowed in integers, but are allowed in decimal whole and exponents by my reading. I do not see support for your assertion "even for floats" - the constraint is listed only for integers).

Thus I would expect that any leading 0s in an integer (with or without N suffix) should be invalid, yet they are all read as octal. So that seems like a potential bug. Because clojure.edn is a superset of edn, you could potentially contend this is additive syntax/semantics beyond edn but seems a little confusing.

For floating points, by my reading, leading 0s in whole or exponent parts are allowed, so no issue or difference from Clojure or Java there afaict.

Comments

Logged the octal reading in clojure.edn as https://clojure.atlassian.net/browse/CLJ-2933

---

I was referring to this part of edn specification when I say "even for floats":

    floating-point-number
      int M
      ,,,
    digit
      0-9
    int
      digit
      1-9 digits
      + digit
      + 1-9 digits
      - digit
      - 1-9 digits

Based on this 042M is invalid number according to edn spec but clojure reads it as BigDecimal 42.