kelthan
Joined 3 years ago
Joined 3 years ago
I guess the alternative is to get a portable high-output single burner butane stove that I can pull out when I want to arroser a steak, for example.
The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the application does something with the "bigbucket" structure--which it can't safely do (see below).
There is no corresponding free() call, so data put into the "bigbucket" structure is never removed, even when the memory allocation is freed by the application. This, by definition, is a leak, which is ironic.
In an application that does a lot of allocations, the "bigbucket" structure could exhaust the heap even though there are zero memory leaks in the code. Consider the program:
int main(int argc, char** argv) {
for (long i = 0; i < 1000000; i++) {
void *foo = malloc(sizeof(char) * 1024);
free(foo);
}
return 0;
}
At the end of the million iterations, there will be zero allocated memory, but the "bigbucket" structure will have a million entries (8MB of wasted heap space on a 64-bit computer). And every pointer to allocated memory in the "bigbucket" structure is pointing to a memory address previously freed so now points to a completely undefined location--possibly in the middle of some memory block allocated later.There are already tools to identify memory leaks, such as LeakSanitiser https://clang.llvm.org/docs/LeakSanitizer.html. Use those instead.
Modern CPUs have more memory built in to L1, L2, and L3 caches than most computers had in total working memory until memory started getting cheap.
I agree with the author that has lead to some "sharp edges" for the API, but that is a normal growth pattern. I'm not saying that the API doesn't have to change, but I did want to make sure that people understand that the creators of the old APIs were not stupid, they just faced different constraints than we do now. And that led to API "shapes" that may be surprising and frustrating to use now, but made perfectly good sense at the time.
Now back to the thread:
It turns out that most people expect "random" to mean a random selection without duplication (at least until the source is exhausted). That is called a non-replacement randomization: once a song (or comic, or whatever), is played/displayed, that item is no longer considered as part of the pool for future selection. However, that requires saving state for the individual user to save which information has been presented to this specific user, which adds a whole lot of additional requirements for cookies, or account registration, or other things that we all generally loathe.
The fundamental problem here is that most people don't really understand randomness and probability. If they did, casinos and lotteries would be out of business (see The Gambler's Fallacy[1]). This is not a failure of education, or mental capabilities: it is a fundamental friction with the way that the human brain has evolved.
The human brain is fundamentally a pattern matching system. We look for "meaning" by identifying patterns in our world and extrapolating what actions we should take based on those patterns. As such, we assume that _all_ systems have memory because that's how humans learn and take action, so we generally assume everything else does, too. But truly random events have no memory: there are streaks that appear "non-random" to us, such as multiple tails occurring in a streak during a fair-coin flip. But streaks often occur in truly random data, we as humans just don't expect it.
The existence of the Feynman Point[2] is an example that even someone well versed in randomness and math thought that a string of six 9's appearing in the value of PI, an irrational number, was something worth noting.
[1]: https://www.investopedia.com/terms/g/gamblersfallacy.asp [2]: https://en.wikipedia.org/wiki/Six_nines_in_pi
Genomic data doesn't have the same risk factors--at least at the moment. I think that the point many are trying to make here is that there may be risk vectors available at some point in the future that aren't known now. A couple of theoretical examples:
* You had to give a blood sample rather than other biometric data like a retina scan.
* Spoofing DNA evidence. That would be very/prohibitively expensive/difficult at the moment, but I suppose could become as easy as 3d printing at some point in the future.
This isn't a case of a minor change to consumer rights in the TOS like changing who would arbitrate a case. It's a significant restrictive change to the rights of the customer in favor of the company. And it was made after a security breach that affected a huge portion of the companies clients which is likely to trigger lawsuits of the form that the TOS now seeks to restrict.
This is clearly a case of attempting to close the barn door after the horse was spotted in the next county over.
I suspect that a competent lawyer could fairly easily argue that this "automatic opt-in" is the same thing in a slightly different format.
The only other thing that they could say would be "We do not comment on matters involving pending litigation." But that's just a longer way of saying "No comment." It's not any more satisfying for the customers or partners understandably seeking answers to what happened, how, and why.