Well, without knowing the language I suppose it might compile, but I'm pretty sure it'd croak on the third statement.

Not sure it's all that big of a deal, really. The USA has a history of ignoring the inconvenient parts of trade deals or any rulings against them, anyway.

Security's motto: We break stuff, put ALL the burden on the users, walk away AND we get paid for it!

This is pretty much what happens when "Security" is a separate business group. Security-oriented admin groups can usually manage to balance security versus operational requirements, but if your only job is making things more secure and there's zero penalty for making things non-functional, well... honestly, I'd probably do the same thing.

At least, assuming these tweets are ranked appropriately.

Down near the bottom, with the ad spammers.

But really... what the fuck, Google? The most "useful" kinds of tweets are the ones who reference the authoritative material that you'd want to see instead of any tweet about it. As a means to add to the page rank of good (i.e. referenced) pages tweets might be valuable, but otherwise twitter activity is pretty much the definition of irrelevant.

I feel like a school janitor sometimes...

3 (different) house keys, shed key, car key/dongle, minivan key, van key, carabiner, Gerber Curve, bottle opener, sparkplug gapper (AKA flat screwdriver which fits everything), nano LED light.

That's all I can remember, anyway.

Name diseases after serial/mass killers and cults, with some consideration given to their body counts.

I'm not sure I'm following. If we're non-POSIX, then what read(2) are we talking about? Also, that sizeof is by definition 1

POSIX defines sizeof(char)==1. But C itself doesn't necessarily *require* sizeof(char)==1, just that char is the smallest non-bitfield type. Theoretically, sizeof(char)==4 could be legit on some architectures. In practice, I doubt there's a non-trivial C program on the planet that would function on such a platform, but it's there.

The *point* of this being that the bug wasn't specifically that sizeof(char)==2, but that sizeof(char) was apparently variable within one trivial function in thousands of lines of code, and that throwing a trivial assertion in front of it was enough to change the value back to what it was supposed to be.

If a no-op changes behavior of your program, then yes, it's either a compiler bug

Exactly. In this case, it was the optimizer losing its shit. I wouldn't try to diff optimized and non-optimized ASM output from the compiler these days, but at the time it wasn't too horrible.

If that was indeed mid-late 90's MSVC++, then that makes it slightly easier to believe, yes ;)

It was still better than g++ on the DEC Alpha around that same time, but that's setting the bar pretty low.

It should be as simple as saying "Nope, not me!", and it's actually the credit card company that has been defrauded, not you.

See also: https://www.youtube.com/watch?...

I've been coding in C long enough to know the difference between unspecified/undefined behaviour and bona-fide bugs.

For example, I'm pretty darn sure that a chunk of code such as:

unsigned char inbyte;
read(fd,&inbyte,sizeof(inbyte));

should always read at most the same number of bytes (one byte would be nice, but let's pretend we're non-POSIX, here...). And if you *change* that chunk of code to something like, say:

unsigned char inbyte;
assert(sizeof(inbyte)==1);
read(fd,&inbyte,sizeof(inbyte));

It should *still* read at most the same number of bytes as the first chunk of code. If the second chunk of code reads 1 byte while the previous chunk of code was reading 2 bytes (and, incidentally, bashing the stack while dumping those 2 bytes into a 1 byte variable), I'm comfortable in calling that a compiler bug.

Mid-late 90's Visual C++, in case you weren't aware, was not a good vintage.

"/* ugly hack to... */" is a modest expression of pride describing concise, functional, readable and elegant C code...

Speak for yourself.

I usually use the expression "ugly hack" to describe the stupid shit I need to do to get around compiler or library bugs.

Because it is by design able to access a hell of a lot more than other languages. How many languages have direct hardware access? Or inline ASM code?

Amen.

As a rule of thumb, any code (in any language) that deals directly with hardware and doesn't have at least a few commented hacks should be treated with suspicion. It likely either doesn't work, the hackery is too subtle for mortals to comprehend, or the person writing the code is so clueless that they don't recognize when they've transgressed into writing horrible hacks.

So, basically, it's going to be just like school is today, except the teachers will be working remotely?

I suspect that veteran teacher has been doing it so like that he can't get outside of the box and imagine education without classrooms, schools, or even structured classes.

I think the future is going to look a lot more like home schooling (possibly in groups to get around the whole school-as-babysitter issue that allows parent to hold jobs) than anything close to the institutions teachers currently work in.

Copyright needs to (I reckon) end with the death of the creator; simple.

Given that we've established that the entertainment industry is a collection of sociopathic asshats, are you quite sure you want to give them a genuine monetary incentive to, say, kill copyright holders in order to plunder their now-orphan works?

Then there's the whole question of figuring out if/when a creator died.

A reasonable fixed term from publication/creation makes the most sense. Emphasis on "reasonable".

34% of users can't tell their iPhones not to connect to a hotspot named attwifi. That sounds like the ability to force connection to a WiFi network to me.

I'm thinking that if a malicious hotspot cycled through the known pre-installed SSIDs like "attwifi", common open SSIDs like "linksys", "NETGEAR", "dlink", "default", etc, plus corporate branded/hotspot SSIDs such as whatever Starbucks or McDonald's use, they could easily increase the vulnerable population to well over 75%.

Don't worry, after a while you'll stop caring about having anything correct in the summary at all.

Then you'll be fully qualified as a Slashdot editor.