On Sat, Jun 15, 2019 at 09:28:05PM +0200, Mattias Andrée wrote:
> `long double` is able to exactly represent all values exactly
> representable in `uint64_t`, `int64_t` and `double` (big float
> can be used for other languages).
Not guaranteed. What exactly a long double is, is different for each
On Sat, 15 Jun 2019 22:11:13 +0200
Wolf wrote:
> Hello,
>
> On , Mattias Andrée wrote:
> > Wouldn't it just complicate matters if you needed to specify whether a
> > number is an integer or a real value;
>
> Could you not just consider sequence of [0-9]+ to be an integer and
> anything with
Hello,
On , Mattias Andrée wrote:
> Wouldn't it just complicate matters if you needed to specify whether a
> number is an integer or a real value;
Could you not just consider sequence of [0-9]+ to be an integer and
anything with other characters either invalid or float? Not sure, I'm in
no means
`long double` is able to exactly represent all values exactly
representable in `uint64_t`, `int64_t` and `double` (big float
can be used for other languages). Wouldn't it just complicate
matters if you needed to specify whether a number is an integer
or a real value; if there is any need for it,
On , sylvain.bertr...@gmail.com wrote:
> json almost deserves a promotion to suckless format.
Except for not putting any limits on sizes of integers. I think it would
be better to have size the implementation must support to be json
complient. And also having separate int and float types. Because
As foreseen, json is kind of a no brainer.
I did write my own parser following like an idiot the specs.
The only trick was to be carefull that the root "element" is not a
normal "element".
It's callbacks based, like the xml parser from hijo.
json almost deserves a promotion to suckless format.
