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.
The only time I have ever been aware of hitting a mobile site is when you have that "gah, WTF is this crap?" moment where you can't find anything and the link you followed has been swallowed by the crap which has said
:"hey, you're on a mobile, how about we fail to show you what you were looking for?".
Their guidelines suggest suggest this is one of those things that will be punished. Which makes this smartphone user quite happy.
I'm kinda hoping that having a handwriting engine allows them to do something useful, like OneNote-style integration with Google Docs.
What's worse than the apps on an Apple watch?
A 2 hour podcast about the Apple watch.
Keep in mind that you're looking at people who spent hours upon hours writing blog posts speculating about the leather and alloys Apple would be using in their watch bands.
A 2 hour podcast about an actual shipping device seems comparatively reasonable.
Yeah the MS junk won't be installed into CM just yet - but wait until that "Deep integration" Kirt McMaster keeps talking up starts happening - you're going to see architectural changes happen in CM designed solely to be beneficial to Microsoft.
Well... I'm less certain of that.
CM/Cyngn has to walk a fine line between making investors/partners happy and not pissing off the CM community. They don't make money from the community, but the community is a huge QA base and they'll have a lot of trouble developing and supporting Cyanogen OS without it.
If they ram through MS-specific stuff (versus just expanding the capabilities of the OS for everyone), a huge chunk of the community is going to bail on them.
I don't think they're quite stupid enough to do this. But I did say "Yet", because
The use of money is all the advantage there is to having money. -- B. Franklin
