What’s your favourite illuminant? http://justine.lol/dox/illumination.txt It makes sense that black people might want to explore different ones than D65 if we consider the history of CIE colorimetry. Has anyone actually done a scientific inquiry into their ability to perceive radiation?
Have they been dna tested? My family came to this great country from England in the 1600s and the women in my family have been helping to keep the traditions of the Penobscot tribe alive because they’re such a spiritual people. White Indian women of faith don’t build casinos.
It's honestly not that difficult to be rigorous. The things you mentioned in the blog post are pretty obvious forms of degenerate practices once you get used to seeing them. The best way to make your argument would be to bring up pointer overflow being ub. What's great about undefined behavior is that the C language doesn't require you to care. You can play fast and loose as much as you want. You can even use implicit types and yolo your app, writing C that more closely resembles JavaScript, just like how traditional k&r c devs did back in the day under an ilp32 model. Then you add the rigor later if you care about it. For most stuff, like an experiment, we obviously don't care, but when I do, I can usually one shot a file without any UB (which I check by reading the assembly output after building it with UBSAN) except there's just one thing that I usually can't eliminate, which is the compiler generating code that checks for pointer overflow. Because that's just such a ridiculous concept on modern machines which have a 56 bit address space. Maybe it mattered when coding for platforms like i8086. I've seen almost no code that cares about this. I have to sometimes, in my C library. It's important that functions like memchr() for example don't say `for (char *p = data, *e = data + size; p<e; ...` and instead say `for (size_t i = 0; i < n; ++i) ...data[i]...`. But these are just the skills you get with mastery, which is what makes it fun. Oh speaking of which, another fun thing everyone misses is the pitfalls of vectorization. You have to venture off into UB land in order to get better performance. But readahead can get you into trouble if you're trying to scan something like a string that's at the end of a memory page, where the subsequent page isn't mapped. My other favorite thing is designing code in such a way that the stack frame of any given function never exceeds 4096 bytes, and using alloca in a bounded way that pokes pages if it must be exceeded. If you want to have a fun time experiencing why the trickiness of UB rules are the way they are, try writing your own malloc() function that uses shorts and having it be on the stack, so you can have dynamic memory in a signal handler.
> It's honestly not that difficult to be rigorous.
Ok, let's try it. I pointed GPT 5.5 at the smallest part of cosmopolitan as I could find in two seconds, net/finger. 299 lines.
describesyn.c:66: q + 13 constructs a pointer that can point well beyond the array plus one element.
C23 6.5.6p9:
> If the pointer operand and the result do not point to elements of the same array object or one past the last element of the array object, the behavior is undefined
Now… you may be trolling, but I do feel like this disproves your assertion. Not you, not me, not Theo de Raadt, can avoid UB.
> the compiler generating code that checks for pointer overflow.
Do you need to check for that specifically? What pointer are you constructing that is not either pointing at a valid object correctly aligned (not UB), or exactly one past the element of an array?
Do you mean for the latter, in case you have an array that ends on the maximum expressible pointer address?
I'm a bit unclear on what you mean by "pointer overflow". From mentioning 56 bit address spaces I'm guessing you mean like the pointer wrapped, not what I pointed to in cosmopolitan, above?
Ok, to be clear that it's not just that one type, if you forgive that one:
net/http/base32.c:64: read sc[0] even if sl=0. I assume this is never called with sl=0, so could be fine.
net/http/ssh.c:355: pointer address underflow? Should that be `e - lp`?
net/http/ssh.c:209/229: double destroy of key. can this code path have non-null members, meaning double free? Looks like it, since line 207 does the parsing and checks that parse worked.
net/http/ssh.c:123: uses memset, which assumes that it sets member variable pointers to NULL (per my post, depending on that means depending on UB), and later these pointers are given to free(), so that's UB.
I won't look deeper into net/http, but presenting just the possibly incorrect remaining comments from jippity:
- ssh.c:211 and parsecidr.c:44: length-taking APIs use unbounded strstr() / strchr(), so explicit n with non-NUL-terminated input can read beyond the buffer.
- tokenbucket.c:77 and tokenbucket.c:92: x >> (32 - c) is UB for c == 0 and for out-of-range c.
- isacceptablehost.c:68: long numeric host labels can overflow signed int b before the function eventually rejects/accepts the host.
> For most stuff, like an experiment, we obviously don't care, but when I do, I can usually one shot a file without any UB (which I check by reading the assembly output after building it with UBSAN)
Does this depend on the project, or part of a project? I'm wondering how far that scales, I don't know labor intensive it is -- maybe you can just look at the output and see that nothing funny is happening?
The compiler is still able to devirtualize and inline the p->f() call, even with an external linkage call preceding it. https://clang.godbolt.org/z/jE3o56ozz
That's interesting that it does devirtualise in practice, but I'm talking about whether it ought to be allowed to. The conclusion I reached is that it ought not to be, making the behaviour you demonstrated a compiler bug. With that said, it was a while ago, and I may have gotten the details wrong.
This is great example of the toxic effect money has on open source. Reward people with respect and recognition instead. Weird anonymous accounts no one's ever heard of will leave, because someone (or something) who's concealing their identity has nothing to gain from recognition. Honestly GitHub should have a real names policy. Because if you're not Satoshi Nakamoto then there's only three reasons I can think of to be anonymous on GitHub: (1) to avoid obtaining your employer's authorization, (2) to spam, harass, and engage in toxic behaviors, or (3) you're not even human. All three of these are the last things I want when engaging on the GitHub platform. Don't get me wrong, I love robots. But I'm perfectly capable of talking to the robot on my own. I don't want to talk to your robot. I also don't want people slipping me intellectual property below the board without their employer's consent. And I certainly don't enjoy all the hate and harassment. GitHub has tried to help with the last part, by making overt displays of hate something that can get you in trouble. The issue is that people just get more guilesome with more anonymous accounts, because the issue was never disrespect (which can actually be strategic and pro-social if we look at Torvalds' career), but rather bad faith participation. If GitHub can guarantee that all its users are human real names good faith actors, then we might be able to start talking about open bounties.
Linux kernel contribution policy required sending patches under real name, but that policy have been lifted about 2 years ago. Now they allow pseudonym contributions.
> someone (or something) who's concealing their identity has nothing to gain from recognition
The xz supply chain attacker hid their real identity, created fakes one and gained recognition over time in order to gain more access and add the backdoor. So TLAs and other bad actors at least are interested in gaining recognition.
I know, right? It's like, finally—a threat actor who's intelligent enough to understand what capital means in the open source community and is willing to devote resources to engage with it authentically (even if it's for evil nefarious ends). The xz incident showed that the open source community has many other good defense mechanisms for verifying and spotting malicious work and then solving it. But we won't even get to play that game if we're inundated with anonymous agent spam so that GitHub can juice its MAU numbers. Maybe they should require every account buy a $40 yubikey. I don't know what the answer is. But I know that no one gains when your measure of success is driving the cost of burning open source developers out down to literally zero.
The xz incident was only discovered by accident, not by someone actually verifying the tarball and test cases were not malicious. We still don't have verification of tarball build reproducibility anywhere. The closest you can get to verified builds is what the bootstrappable builds community built in hex0/stage0, and what stagex built on top of that. I'm guessing even they haven't read through all that source code though. There aren't even good tools for distributing reviews, there is crev, but the stagex folks think it has some deficiencies.
I don't know what the solution to slop is. Maybe the bubble will implode at some point. Until then, just close down issues/pulls or remove projects from GitHub I guess.
I recall reading it and you mischaracterize and conflate the core issues with accusations of hate and mean words, which is an inappropriate deflection and an attempt to control the narrative. The core issues were always plagiarism, misrepresentation of another user's work, refusal to give proper credit to the real author, and you bragging about it when you thought you could get away with it with quotes like "great artists steal." You never took accountability nor grasped the seriousness of what you attempted to do. You don't seem to understand WHY you faced blowback. You never expressed regret that the person you were victimizing was deeply depressed and pushed moreso by your betrayal. It's always "me, me, me." Your behavior and response is toxic.
Stealing code and credit (and being unrepentant) is actually what gets you into situations like that one. I read your document and you still seem to think you're a victim.
Also I must've been mistaken about you having been unbanned from llama.cpp, as I'm sure you're aware that being so brazen and unrepentant about your plagiarism and victimization of another developer would have risked your access once again. It's a shame you've not grown as an open source contributor
There are a million doctors in the U.S. so if they're each seeing 60 patients per day that would mean that 17% of the population needs to be seen by a doctor daily.
That would put hospitals somewhere between churches and offices in terms of the impact they have attracting attendance.
That's not what the post you're replying to said, at all.
I'm not in a position to evaluate whether they were right, but you've presented this as if it proves them wrong when it's barely related to what they said.
of course I have an adblocker, have you tried going online anytime the past 20 years ??? also, I don't know how to install chrome extensions on firefox so that's probably not for me.
My comment was not about that site itself, but about its content and that someone cared to share the link to it :)
