Here's something close to what you want...Covid19 infections (not deaths) by percentage of people infected each day, per county:
https://www.facebook.com/Arsla...

Now I wonder how many posts have a sig that is funnier than the post itself.

When my friends ask me if we'll ever have true AI, I tell them to look at people such as these. And my friends realize that a lot of human intelligence is artificial.

Nonsense! Javascript slows down the browsing experience. Doesn't matter how fast your hardware is; it is always faster without Javascript. Not to mention security issues.

I sure hope someone at Dice is testing beta using lynx! (or links)

Government agencies have been caught lying, but they don't have the same legal requirements to citizens as publicly-traded companies have to shareholders.

I think I've found the problem right there!

I SOOOOO want to see this answered!

Thanks for this notice. I've added it to our 'Errata', so it should be fixed in the next reprinting.

It is more a style issue rather than a correctness issue (the code in the book *is* correct), but we should also be promiting good style too :)

Well, C's free() is a library function, so it only gets a pointed-to value, not the actual pointer itself. But if free() could magically null the pointer, would that solve your problem? Your program could have other copies of the pointer that free() wouldn't know about; those would still be dangerous.

Java's GC fixes this problem by freeing memory only when it knows no object references point to it.

Agreed. Java did get some things right. When was the last time someone took advantage of a buffer overflow in a Java program? (I'm talking about the Java language here, not about vulnerabilities in particular implementations of Java.) The fact that it garbage-collects memory for you is not only convenient, but closes off a whole class of vulerabilities like double-free, that still plague C/C++ programmers.

On top of that, Java provides a standard API for concurrency...standard C and C++ didn't provide any threading model until this year.

And Java provides a framework allowing a program to run hostile code and still maintain control. C has no such capability; if your C program runs hostile code, game over, you're pwned. So I'd say Java did solve some of the biggest problems affecting C...buffer overflows and memory-allocation errors. I'd say that makes Java more secure than C. The problems outlined in the book can mostly be applied to C as well, though you'll have to go outside the standard to do them (eg for multithreaded code).

I'd say that no language provides security, as perfect security is an impossible dream...we can strive for it, and approach it, but never quite reach it. So I'd rather say that Java provides more security than C.

No, but here is a translation you'll understand:

Project code = getProject();
int softwareQuality = QA.getQuality( code);
Date deadline = Boss.getDeadline();
Date completionDate = estimateRemainingWork( Project.codingQuality);
while (completionDate > deadline) {
    Project.codingQuality--;
    completionDate = estimateRemainingWork( Project.codingQuality);
}

I think that needs to be updated:

Pwn once.
Patch everywhere.

Let me explain...no there is too much. Let me sum up.

I've read 1000-page technical books that had no filler (at least none that I could find). They just had a LOT of ground to cover. Sigh. How do you distinguish the books with mostly filler from the books that aren't? You gotta slog through the whole thing. Or you gotta trust that that review you're reading was done by someone who slogged through the whole thing.

Sounds like you want more of a tutorial in the style of K\&R, rather than a reference book like this.

I'm not sure what you are referring to on page 25, there is no doPrivileged() block there. But go ahead & contact me with specific criticisms or comments on the rules.

Some of the problems you cite arise from the main purpose of the code examples, which is to be illustrative, rather than to be functional. For example, I'll agree that magic numbers in code are generally a bad idea, and should be replaced with constants. In fact, we considered adding a rule about this to the book, and nixed it because that is purely a maintainability issue, with no direct ramifications to security. (That is, you'd have to work hard to contrive an example where failing to use magic numbers makes your program vulnerable rather than just buggy.)

Using 'magic numbers' also makes the code bigger, and a little harder to read. For code whose purpose is to work properly, this extra code size is no big deal, but when the code's purpose is to serve as an illustration in a book, this bloat is more problematic. If the code has to appear on a PowerPoint slide, this bloat can be critical.

I suspect the ediface you are imagining is a tower of babel...it will never be complete. True security is an impossible dream, that we can asymptotically approach yet never attain. In this book, we tried to focus on the insecure coding practices being made today; we ignored 'theoretical' insecure coding practices that aren't being widely done today. Mainly to keep the project a manageable size :)

That's what you get for skipping the article.

So let me see if I get this straight...

The current system allows a taxpayer to be dishonest, but catches him if he is.

The proposed change prevents a taxpayer from being dishonest (by informing him of what the IRS already knows of his finances), and only gives him a chance to correct the records.

So how is catching taxpayer dishonesty an advantage, again?