Glad you like it!
5,314 karma · joined February 16, 2015
Blog: https://gavinhoward.com/
Contact: https://gavinhoward.com/contact/
Glad you like it!
[1]: https://gavinhoward.com/2023/02/my-code-conquered-another-os...
The author is correct on the parsing of "normal" vs. Reverse Polish notation. My `bc`, with normal expressions, needs 1555 LoC for parsing. My `dc` needs just 298.
I have a couple posts ([1], [2]) about `dc` tricks and code on my blog.
And yes, I have an HP 48G [3]. :)
[1]: https://gavinhoward.com/2019/12/bc/dc-tips-and-tricks/
[2]: https://gavinhoward.com/2021/04/a-dc-script-for-easter/
[3]: https://gavinhoward.com/uploads/easter-dc-script/hp-48g.jpg
What we need is true supply chain security, but no one is willing to pay for that; it would mean paying FOSS projects, and companies don't want to pay for their "free" software.
https://gavinhoward.com/2024/03/what-computers-cannot-do-the...
This is why I have a separate config language and code language.
My config language is essentially JSON with newline separators and a first-class binary type (base64). I added little else.
When I get the temptation to add code to it, I just pull out my other, general-purpose language instead.
I do wish I had more context from the video, but at this point, it's getting hard to imagine any good reason for Defcon to do what they did. Assuming that you weren't threatening someone in the audience or something like that. Doubtful, from the way you've been talking.
Anyway, it looks like good stuff. Wish I had some Game Boy games to try it.
But even so, dragging a presenter off stage is sus. And doesn't seem smart because even if the other claims are not true, I'm tempted to never attend Defcon if that's what they do.
As a one-man programming team, you are correct. And quite frankly, I shudder to think of not programming with a test suite or version control, even though I work alone!
Docs, tests, and version control reduce what I have to remember about the code context. Yes, I have to remember the details of the code in front of me, but if I document it, test it, and check it in with a good commit message describing the why and how and whatever, then I can discard that code from my memory and move on to the next thing.
No, it means that the bug is documented to be in the platform, not the program.
> If this is such a big issue for you, you could just name another example. It'd take, like, 5 words to say another feature in question unnecessarily changed.
Okay, how about `signal()` being called in a multi-threaded program? Why couldn't they define it in C11 such that it could be called? Obviously, such a thing didn't really exist in C99, but it did in POSIX, and in POSIX, it wasn't, and still isn't, undefined. Why couldn't WG14 have simply made it implementation-defined?
> I quite like that my compiler will optimize out dead null comparisons or some check that collapses to a 'a + C1 < a' after inlining/constant propagation.
I'd rather not be forced to be a superhuman programmer.
Backwards compatibility? I thought that was a target for WG14.
> This is just standard backwards incompatibility, nothing about UB
But UB is insidious and can bite you with implicit compiler settings, like the default to C99 or C11.
> whether the C standard should always be backwards compatible is more interesting, but is a question orthogonal to UB
If it's a target, then it should be.
And on the contrary, UB is not orthogonal to backwards compatibility.
Any UB could have been made implementation-defined and still be backwards compatible. But it's backwards-incompatible to make anything UB that wasn't UB. These count as examples of WG14 screwing over its users.
> I do remember some mention somewhere of a real platform in fact not handling size 0 properly being an argument for reducing the standard requirement.
So WG14 just decides to screw over users from other platforms? Just keep it implementation-defined! It already was! And that's still a concession from the pure defined behavior of C89!
> I had edited one of my parent comments to mention realloc, so if we both landed on the same example, there's probably not that many significant other cases.
I beg to differ. Any case where UB was implicit just because it wasn't defined in the standard could have easily been made implementation-defined instead.
Anytime WG14 adds UB that doesn't need to be UB, it is screwing over users.
But if you must have a concrete example, how about realloc?
In C89 [1] (page 155), realloc with a 0 size and a non-NULL pointer was defined as free:
> If size is zero and ptr is not a null pointer, the object it points to is freed.
In C99 [2] (page 314), that sentence was removed, making it undefined behavior when it wasn't before. This is a pure example of behavior becoming undefined when it was not before.
In C11 [3] (page 349), that sentence remains gone.
In C17 [4] (page 254), we get an interesting addition:
> If size is zero and memory for the new object is not allocated, it is implementation-defined whether the old object is deallocated. If the old object is not deallocated, its value shall be unchanged.
So the behavior switches from undefined to implementation-defined.
In C23 [5] (page 357), the wording completely changes to:
> ...or if the size is zero, the behavior is undefined.
So WG14 made it UB again after making implementation-defined.
SQLite targets C89, but people compile it with modern compilers all the time, and those modern compilers generally default to at least C99, where the behavior is UB. I don't know if SQLite uses realloc that way, but if it does, are you going to call it buggy just because the authors stick to C89 and their users use later standards?
[1]: https://web.archive.org/web/20200909074736if_/https://www.pd...
[2]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
[3]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
[4]: https://web.archive.org/web/20181230041359if_/http://www.ope...
[5]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
Edit: okay, not all of it. I was hyperbolic. Race conditions and data races should be UB. But anything that can be implementation-defined should be.
And the compiler writers have a stranglehold on the standards bodies. They hold more than 50% of the voting power last time I checked.
So yeah, compiler writers decide what's UB.
Except that compiler writers essentially decide what's UB. Which is a conflict of interest.
And they add UB, making previously non-UB code fall under UB. Would you call such code buggy?
My first Linux machine was `congo`. My oldest extent one is `volga`. And my beefiest (biggest) machine is `nile`.
My local backup NAS is `danube`, and my offsite server is `yangtze`.
If I were you, and didn't want boring job-themed names, choose a theme and use it.
You could choose mountains, and your biggest machine could be `everest`, while your most sacred could be `olympus`.
Or you could choose cities, Pokemon, anime characters, authors, fish, mammals, etc. Any category with a lot of items. Seas, for example, won't work because there aren't many.
A static site generator is probably best, but the best one for you comes down to preference.
> And, to echo sentiments voiced by other replies, the anti-government hyperbole is more kooky than persuasive.
I am serious about it, not hyberbolic, but I will plan to leave it out of future stuff about this.
Yes, it is, and I am all for good regulations.
> The question isn't whether the industry will get their act together before governments start moving (they most definitely won't)
I wrote this post to change this.
> it's whether governments will give the industry a window to self-regulate under direct and explicit threat of intervention or if they'll immediately start writing the regulations themselves.
EU's Cybersecurity Resilience Act shows that they are already doing the latter.
The things I linked to are ideas. Others will have ideas too. Let's come to a consensus about them.