151–160 of 248 posts
This is rather lenient. There's not anything wrong with that (although perhaps it should be noted for people that will use it without looking at the code), but it's the main reason this can be so small. Using their demo in the readme: {"x",10eee"y"22:5,{[:::,,}]"w"7"h"33 rect: { 10, 22, 7, 33 }
I don’t know what else you call a library that just extracts data.
Earlier quoted context omitted.
2GB in a single JSON file is definitely an outlier. A simple caveat when using this header could suffice: ensure inputs are less than 2GB.
Not really. I deal with this everyday. If the library has a limit on the input size, it should mention this.
Earlier quoted context omitted.
This has nothing to do with memory safety.
This is an overstatement. Yes, UB does not necessarily cause a violation of memory safety, but triggering UB alone is not the goal of an attacker. UB is a means to an end and the end is usually a violation of memory safety leading to arbitrary code execution.
UB was a secondary observation, but it also can lead to logic errors in that vein, without involving memory safety.
I'm not sure I agree that UB usually leads to memory safety violations, but in any case, the fact that signed integer overflow is UB isn't what makes the code incorrect and unsafe in the first place.
What I love about this author's work is that they're usually single-file libraries in ANSI C or Lua with focused scope, easy-to-use interface, and good documentation. And free software license. Aside from the posted project, some I like are: - log.c - A simple logging library implemented in C99 - microui - A tiny immediate-mode UI library - fe - A tiny, embeddable language implemented in ANSI C - microtar - A lightwe…
Earlier quoted context omitted.
What is the stance of Your Average Corp’s security department on public domain software? Do they accept software under such licensing (or lack thereof)?
Who cares? Seriously. Whether a commercial entity who wants to be able to benefit from your work accepts the license you choose for work you do is as much a concern as whether or not the prime minister of Liechtenstein accepts the color you paint the outside of your house in the USA. That is: none.
Earlier quoted context omitted.
It's open source, not free software.
"Source Available" and "Open Source" (with an OSI-approved license) are the terms you're looking for. "Free as in speech, or free as in beer?" is your rallying cry.
Earlier quoted context omitted.
Who cares? Seriously. Whether a commercial entity who wants to be able to benefit from your work accepts the license you choose for work you do is as much a concern as whether or not the prime minister of Liechtenstein accepts the color you paint the outside of your house in the USA. That is: none.
Kinda depends on whether you're publishing open source software so that people can use it. And if you're not publishing open source software so that people can use it, why exactly are you doing it? If you don't want people to use it, GPL is the way to go. If you do want people to use it, MIT or BSD is a much better way to go.
People != the legal departments of corporations.
Earlier quoted context omitted.
Who cares? Seriously. Whether a commercial entity who wants to be able to benefit from your work accepts the license you choose for work you do is as much a concern as whether or not the prime minister of Liechtenstein accepts the color you paint the outside of your house in the USA. That is: none.
Bad analogy.. if they truly care what colour your house is then there's plenty of strings they could pull. I mean, a good number of large U.S. company's tax and corporate structures depend heavily on Liechtenstein's government’s rules..
Earlier quoted context omitted.
There was a nice article [0] about bloated edge cases libraries (discussion [1]). Sometimes, it's just not the responsibility of the library. Trying to handle every possible errors is a quick way to complexity. [0]: https://43081j.com/2025/09/bloat-of-edge-case-libraries [1]: https://news.ycombinator.com/item?id=45319399
Strongly disagree here because JSON can come from untrusted sources and this has security implications. It's not the same kind of problem that the bloat article discusses where you just have bad contracts on interfaces.
Using a "tiny library" for parsing untrusted data is where the mistake is. Not in OP code.