Older applications not targeting M, will show permissions at install time and be granted by default, but the user will be able to revoke them, the platform will just give empty data or fail.
Both of you are idiots.
For a second there I thought you might have a good point. Then you kept typing and showed that you're just another asshole.
You said " someone needs to get cracking with that recall" and "It doesn't invalidate anything I wrote". So what precisely do you expect to be recalled due to this case of a person accelerating a car towards a group of people?
What I wrote stands for the situation described in the headline, summary and article. We'd obviously have to allow for physics (i.e. a car won't stop immediately at 70mph, and pedestrians wearing black radar-cloaking clothing at night are probably fucked), but otherwise get it right or get it off the road.
If the car wasn't actually operating autonomously, sure, what I wrote wouldn't be directly applicable to this situation. It's still the right way to handle the failure at it was described.
That's only true if the capability is supposed to be used without supervision
Hm. Legit point, but then you have to ask whether the driver reasonably understands how the assistive technology works well enough to be able to supervise it, and also how easily they can stop the process if things go wrong (i.e. if the assistive technology requires the driver to take their limbs off the wheel, brakes and accelerator in order to work reliably, then it's pretty much guaranteed that they won't be able to act quickly enough to prevent an accident).
It wasn't doing any autonomous movement so your premise is garbage and thus the rest of the post meaningless.
So, you're saying the "self-parking" bit the headline, summary and article describe is a complete red herring and had nothing to do with what the car was actually doing at the time?
If you say so. It doesn't invalidate anything I wrote, it just might not be applicable to the situation that the headline, summary, and article all apparently failed to describe.
Any vehicle that is capable of any kind of autonomous movement that doesn't include pedestrian (or dog, or cat, or cyclist) detection is defective, period.
Any auto manufacturer that makes such a vehicle is 100% liable for any deaths or injuries that happen during said autonomous movement, period.
This isn't rocket science. This should be considered "seat belt saves lives" level of mandatory.
Now, someone needs to get cracking with that recall...
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.
It is easier to write an incorrect program than understand a correct one.
