Re: [Json] [Cbor] JSON and int64s - any change in current best practice since I-JSON

[Jeremy O'Donoghue <[e-mail]>]

The “technically correct” solution is to follow the standard, but that’s not especially pragmatic.

I think you should probably not allow zero-elision as it sounds like this would be supported by all implementation languages natively.

Requiring a full number-parsing stack for every implementation is a recipe for bugs compared to using built-in language support.

As a minimum there needs to be guidance about the use of in-built language numeric parsers and formatting in the text.

Jeremy

Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: CBOR <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Sent: Saturday, January 27, 2024 2:36:52 PM
To: Joe Hildebrand <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Tim Bray <[e-mail]>
Subject: Re: [Cbor] [Json] JSON and int64s - any change in current best practice since I-JSON

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On 2024-01-25, at 16:20, Joe Hildebrand <[e-mail]> wrote:
>
>> * leading/trailing decimal points.  What is the semantics that need to be defined here?
>
> For leading, probably none.  For trailing, it might be a sign that the number should be treated as floating point, so that there is a difference between `1` and `1.` in environments where there are different types for float and int.  At the very list, the range checking should be different.

Right.
It seems programming languages like Python, JavaScript, Java, C, C++, and FORTRAN allow leaving off all-leading- or all-trailing-zeros in the mantissa (but not both), clearly still treating the number as a floating point value.
This is also part of IEEE 754 5.12.2 “External character sequences” syntax (Section 5.12), and was already in ECMA-63 NR2/NR3 (which became ISO 6093 later).

However, this is not universally supported; a few quick examples (not thoroughly checked, please correct where wrong):
* C# allows eliding all leading zeroes, but not all trailing zeros,
* Rust allows eliding all trailing zeroes, but not all leading zeros,
* Ruby allows neither.

Supporting full FORTRAN syntax here therefore is a bit against my personal style, but I gather I might be in the rough with this against massive historical precedent.

PR in [0], [1], with formatted version at [2], [3].

[0]: https://github.com/cbor-wg/edn-literal/pull/29
[1]: https://github.com/cbor-wg/edn-literal/pull/29/files
[2]: https://cbor-wg.github.io/edn-literal/elide-zero-mantissa-parts/draft-ietf-cbor-edn-literals.html#name-overall-abnf-definition-for
[3]: https://cbor-wg.github.io/edn-literal/elide-zero-mantissa-parts/draft-ietf-cbor-edn-literals.html#appendix-A.1-7.1.1

You can play with this using edn-abnf 0.1.5 (gem update edn-abnf):

edn-abnf -tedn -e +2.
edn-abnf -tedn -e +.2
edn-abnf -tedn -e +.
edn-abnf -tedn -e +2.e2
edn-abnf -tedn -e +.2e2
edn-abnf -tedn -e +.e2

Oh, and while fiddling with this, I found a bug:
The -07 EDN syntax allowed 0x1.3p (zero length exponent), which really needs to be 0x1.3p0.
Fixed in [4] (and included in edn-abnf 0.1.4 and the above formatted text version).

[4]: https://github.com/cbor-wg/edn-literal/commit/6096deb

Grüße, Carsten

_______________________________________________
CBOR mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cbor