221–230 of 248 posts
Earlier quoted context omitted.
I didn’t say it’s the author’s problem. It’s a problem with the code.
Why play all these semantic games? You're saying it's the author's problem. You want them to even edit their readme to include warnings for would be production/business users who don't want to pay for it.
Earlier quoted context omitted.
JSON does not necessarily come from untrusted sources if you control the entire system. Not everything needs to be absolutely 100% secure so long as you control the system. If you are opening the system to the public, then sure, you should strive for security, but that isn't always necessary in projects that are not processing public input. Here's an example - I once coded a limited JSON parser in assembly language.…
I agree. I knew that the JSON is not going to change, so I wrote a 10 lines long parser for it. It is not a JSON parser by any means, but it parses properly what I need it to.
Earlier quoted context omitted.
I agree. I knew that the JSON is not going to change, so I wrote a 10 lines long parser for it. It is not a JSON parser by any means, but it parses properly what I need it to.
sscanf as a parser definitely has its uses
Earlier quoted context omitted.
Actually, you'll hit the limits of DOM-style JSON parsers as soon as your data is larger than about half the available memory, since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory (unless you're able to incrementally destroy those parts of the DOM that you're done with). Anyhow, IMO a proper JSON library should offer both, in a layered app…
> since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory Not really because the JSON library itself can stream the input. For example if you use `serde_json::from_reader()` it won't load the whole file into memory before parsing it into your objects: https://docs.rs/serde_json/latest/serde_json/fn.from_reader.... But that's kind of academic;…
Earlier quoted context omitted.
For something that simple I'd choose a custom binary protocol or something like ASN.1 instead of JSON. It's easier to generate from a HLL and parse in a LLL (I've also been writing Asm for a few decades...)
I would love to use ASN.1 if other programming languages would match up to Erlang's ASN.1. :(
Earlier quoted context omitted.
I controlled both ends. There is nothing "insane" about JSON. It's used far and wide for many purposes. The system sending the JSON was based on Nodejs, so it was pretty natural to use JSON. And I did it with JSON just because I wanted to. I'd have had to invent some other protocol to do it anyway, and I didn't feel like reinventing the wheel when it was quite simple to write a basic JSON parser in assembly language,…
For something that simple I'd choose a custom binary protocol or something like ASN.1 instead of JSON. It's easier to generate from a HLL and parse in a LLL (I've also been writing Asm for a few decades...)
Earlier quoted context omitted.
Or Free as in Ebola, in the case of GPL-licensed software. Whatever happened to Free as in Air and Sunshine?
It was enshittified because there was nothing defending it.
Earlier quoted context omitted.
Being able to parse without a lot of overhead and without allocations is quite interesting. E.g. when you process some massive json dump to just extract some properties (the Wikidata dumps come to mind).
If you want to do that you'd probably want to use a fast SAX parser, not something that naively looks at one byte at a time.