Notices by ThePhD (thephd@pony.social), page 4

We're getting closer...

We keep calling ourselves software engineers, but engineers elsewhere advance their industry by analyzing failures and building up tools to stop those and make them standard industry practice!

But we'll just have the same 6 problems, on a regular spin cycle, for like 40 years.

Oh cool, another Chrome 0-day abusing integer overflow.

Neat.

Great.

Awesome.

Meanwhile, we'll be writing about how we need to have "high impact libraries that help lots of users" and then give examples like CLI Parsing/JSON Parsing before we sit down and go "we should have some standard library types / functions for integers...?".

v.v.v.v. cool prioritization we do here.

I just spent the last 7 hours metaprogramming in C.

Never fucking again.

Good news: typeof(...) enables all the metaprogramming crimes you could ever want to accomplish in C.

Bad news: typeof(...) enables all the metaprogramming crimes you could ever want to accomplish in C.

This picture is kinda OD I might have to use it for any future appearances...

I've always used some form of art, but this might take the cake. Also _Atomic(meow), how could I not?!

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3176.pdf

...

(* deep breath *)

I need to write not only a paper, but a full-blown series on the history of C. The historical revisionism and prescription of some magical properties to C89 or whatever without mentioning the vast landscape of extensions is.

Ugh.

Like. So many people shit on VLAs for being too underspecified and undefined (correct), but then conflate that with it not seeing "greater uptake" and like. No? That's not true? Just talk to anyone working in HPC, it's the fucking bread and butter.

You Are Not The Only Programmer On Earth. Your Domain Is Not The Only Domain That Exists.

You can't say "C is used literally everywhere!" and then put on your blinders when people from those communities bring their extensions from their domains to the wider C programming language, to try and get better support both inside and outside of their domain! That's LITERALLY how the charter works! VLAs were WIDELY implemented when they were standardized, they were WIDELY used when they were standardized, it's ahistorical bullshit to pretend it isn't or wasn't!

They have CLEAR issues with how underspecified and undefined they can be, how much they rely on your implementer to be a literal Divine Hero to get it right, but you cannot be serious that they're (a) not used and (b) not useful. Even _Generic was introduced because of C, not other languages! It was literally HAND-DESIGNED, BY IMPLEMENTERS (not the Committee!!!) to get the job done! Every single time we have this fucking conversation I lose my mind because the actual history is right there, in the paper trail, it's WAY more transparent than WG21/C++, because meeting minutes are ALSO public record! You don't have to just assume or make shit up, it's RIGHT THERE.

Got Stun Locked Again, so it's time to dump a rant I made elsewhere:

C is not a language for direct control of the hardware. C is a langauge that is coded to the semantics of an Abstract Machine specified in a document. It's no more capable of hardware control that e.g. Rust or Zig. What it has is a wide variety of pre-existing implementations that allow you to touch that hardware, but most of that control was programmed in an assembly language or worked into the hardware/firmware by somebody.

C is not more suitable for hardware and your computer is not a PDP-11. (This is part of why "Nobody writes ISO C" is a thing. C, the language K&R made, the language that got standardized, at any point in its lifetime, was never good enough for a kernel. It just let people coordinate stuff in the cheapest way possible and accepted extensions.)

The part that's extra nutso is that the last 20 years were people who held this exact belief -- that C was just a thin layer over the hardware -- get bodied, over and over again. Compiler vendors gave them the big middle finger every time they said "wait, no, UB is for hardware!", and compiler vendors traded in UB for (sometimes negligible) speed ups.

To still believe C is "for the hardware" in today's day and age where GCC will literally run your for loop for eternity because you tried to access an array out-of-bounds and it found out about it, or Clang will solve fermat's last theorem due to a loop, is magic shroom thinking. You can access the hardware just as good with Java by using the Pointer class, you can hit the same register that the shitty ISA Manual fucking lied about by writing the same integer address into the Pointer class and dumping out a 2-byte integer to the right place.

C is not magic and you're not improving its design by insisting it is, for the love of God start Evaluating Your Tools Properly. Yer an engineer, not a fucking wizard, Harry.

Me, watching people in the comments debate just using objcopy to "get the data in faster" when this table exists and was already published on my blog:

https://thephd.dev/embed-the-details#results

One thing I will always be grateful for #embed, std::embed, and std::optional for showing me was that people absolutely do not measure shit. And people will gleefully talk with absolute confidence about things they've never tested, and assumptions they've never actually tried.

@gaycodegal @eniko If someone wants to submit a PR by the name SnakeAssIsThicc, they can and should be able to.

Let me work on your programming Language.

I am

normal

and can be Trusted with Language design.

@a1ba As far as I know, only in a few propretiary compilers. Everyone else is taking their time, because doing the optimized version is a bit harder than what most people expect.

@a1ba The specification is already solid and done (e.g., it's in the standard and implemented by others). Only thing is me trying to make sure GCC and Clang have it.

@koko Put on the Foxgirl Ears, Shinji,

#embed (naive version) is done and polished and ready to be submitted to clang, but I won't submit it until I finish the polished speedy version, because I can't trust implementers

https://github.com/ThePhD/llvm-project/commit/4f81b166f3b896a711a730d3f727b6e7a829ebf1

.... You're telling me fucking webp wasn't running basic fuzzers on its bloody image parsing shit?

Did I just get transported back to 2001? The fuck??

Anyways please fuzz your codebase. If you're deploying something which is intensely focused on things created by users and user tools and exchanged between them frequently, please make sure EVERY part of it is fuzzed, that you have code coverage, and that you can verify every if statement and conditional is being exercised.

Then when you're done with that take your entire dataset and create something that will take random chunks from each one and splice them all together in one file, then throw that input at your test suite.