> The heartbleed vulnerability was not due to mempool. It was due to a combination of lack of bounds checking, and not zeroing out the memory containing secure keys when its deallocated. Even if it didn't use mempool, leaks would still be possible.

I didn't say that the bug was caused by the mempool, I said that the bug was very hard to find by regular tools such as valgrind and UBSan because it used mempools instead of regular allocations - so that all of the logical out of bounds accesses were not actually UB nor were they accessing unallocated memory, which those tools could have caught.

I don't want to defend the esthetic surgery industry in general, which I do think tends to be quite predatory, but doesn't this sound like the opposite of that? If they really wanted to fleece you, wouldn't they offer surgery instead of the safer and cheaper treatments?

I do think the C++ bookkeeping from new[]/delete[] however has few if any similar caveats - the runtime really needs exactly the kind of information you also need in your code; the only caveat I can imagine is that it might omit this information for types that don't need destruction, such as `int`, but I don't know if this is a plausible optimization in realistic use cases that are not trivial.

Well, not necessarily. For one thing, if we have a function foo(int c[]), it's debatable if c is an array variable or a pointer variable. However, what's not debatable is that you can allocate a struct on the heap, and that struct can have an array member - e.g. `struct foo { int a[10]; }; [...] struct foo *x = malloc(sizeof(struct foo));` would allocate an array on the heap as part of the struct.

> That would only be true if each element in the array was a char.

That's why I said that it depends on what exactly you mean by the size of the array. It's also true that in today's world at least, malloc() will often allocate more memory than you actually ask for, to optimize against fragmentation - and then the internally stored size is the size of the actual allocation, not the logical size that you requested - which may not even fit into a whole number of array elements. So, I was being a little overly simplistic (lying) for dramatic effect.

> For example, a really good practice in C coding that basically solves any double free is a mempool that allocates all the memory up front.

While this is a very valid technique for certain purposes, especially when dynamic allocation is needed in very high performance code, it's very much not a valid solution for memory safety - quite the contrary, it's a terrible practice for that. In particular, this is almost exactly the issue that caused the infamous HeartBleed vulnerability in OpenSSL to stay hidden for so long: the use of a memory pool for the buffers used to store TLS packets was hiding the buffer overflow from UBSan and valgrind and similar tools, since the reads were perfectly valid from a language perspective (they were never reading from free()d/unallocated memory, only from memory that had been released to the memory pool).

Array memory can sit on either the stack or the heap.

> The size of that array is actually not known at run time, its only known at compile time, where any reference to that length gets resolved by the compiled.

This is also a bit misleading, in two ways. First, it's not clear what you mean by "size" here - the size of the memory block(s), or the shape of the array?

Second, many people think that the C runtime doesn't know the amount of memory allocated to an array, but this is actually false. It's just the C abstract model that for some reason chose to not expose this information - but the size is actually always stored and accessible, and this is virtually mandated by the standard: otherwise, `free(arr)` couldn't realistically work, it would have to be `free(arr, size)`. This is one of the weirdest inefficiencies of C, in fact - it requires you to store the size of arrays twice - once in user code, and another time in the internal logic of the allocator.

Edit: and as a fun extra, C++ not only inherited this mistake from C, but reproduced it again, meaning that a C++ array allocated with new[] actually stores the size twice, at least with typical implementations - once in the C++ runtime and again in the allocator - and still requires the user-space code to store it a third time. This is because `delete[]` needs to call the destructors of all of the elements of the array, regardless of where and how the array was allocated, so the number of array elements needs to be stored alongside the object itself.

What horrendous morals behind this article. Why would anyone advocate for prioritizing economics and technology before ethics, especially in something as important as law?

The "won't someone think of the all the poor people with no access to legal counsel" part sounds a lot worse once you realize they actually mean "won't someone think of the money we're leaving on the table by not getting some revenue from selling cheaper AI slop, uh I mean AI legal representation, to those who can't afford anything else".

So, while you are right that video streaming is much more costly than audio streaming, I think GP is overall more correct about the reasoning being production costs rather than anything to do with distribution.

Very, very few people, even in tech circles, check the sources of all of their dependencies. Sure, compromising magit's sources will be hard - but you don't need to compromise magit. Just compromise one of magit's dependencies and watch the malware spread.

Edit: in fact, you don't even need to compromise Magit's dependencies. Since the developers of Magit probably use Emacs themselves, you can probably just compromise some small Emacs package that happens to be used by someone on the Magit team, get access to their repo from there, and then you actually may be able to compromise Magit itself (depending on how strict their code review etc rules are).

1. Create a new Emacs package, create a PR to register my GitHub repo as a new package in MELPA's repo, and wait for them to accept the PR. Ideally the plugin should be benign at this point.

2. Wait for people to pick up this new extension, while it's still benign.

3. Push the malicious version to my own GitHub repo. MELPA will automatically pick it up, build it, and package it.

4. Anyone updating their Emacs packages from MELPA or installing it from MELPA will pick up this malicious version.

Now, this does require that the malicious code is visible on the extension's GitHub page; I'm not sure if this would be true on VSCode as well.

So yes, some metaphysical statements are falsifiable, and some have in fact been falsified over time. And, very importantly, many of the biggest metaphysical questions have no known falsifiable answers (at least none that are not already known to be false, of course).

Also, the entire point of p-zombies is that they can, by definition, pass any objective test that we can currently conceive. A p-zombie is, by definition, "something that behaves exactly like a human, but doesn't have any inner consciousness". Of course, just because we can define something at this high level doesn't mean that this thing can actually exist (e.g. we can define the concept "numbers that are bigger than 3 but smaller than 2", despite no such number existing).

This is an metaphysical discussion, so falsifiability is kind of irrelevant. All metaphysical positions are ultimately unfalsifiable - including materialism and physicalism just as much as dualism or monism or theism.

If you want to see an obviously nonsensical world view, you need to look at something like the Time Cube "theory". Rovelli is essentially claiming that dualism is more in this area - which I agree with the GP is quite unlikely for such a long discussed and influential philosophical idea.