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.

Telecom companies are famous for *making* promises.

Making good on them, not so much.

They'd have probably gotten around to your area about the same time as your first Social Security check.

He won't be too old to sit on some corporate Boards of Directors.

What are these multiple providers of which you speak?

Where I live we have the choice of Time-Warner cable or no cable, and there's no sign of that changing in my lifetime.

Are you using caffeine-free soda to test this? Just making sure; headaches are also a symptom of caffeine withdrawl.

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%.