Yes, you didn't RTFA, because your definition actually makes sense. TFA defines "unstable code" as code with undefined behavior.
...and undefined behavior is exactly what causes the things I listed.
TFA also claims that many compilers simply DELETE such code. I have never seen a compiler that does that, and I seriously doubt if is really common.
You probably haven't used any desktop compilers.
Just a sampling:
During MS's security push a decade ago, they discovered that the compiler was optimizing away the memset in code such as memset(password, '\0', len); free(password); that was limiting the lifetime of sensitive information, because the assignment to password in the memset was a dead assignment -- it was never read from (not actually undefined behavior, but it is an example of the compiler deleting unused code that was actually there for a purpose)
I linked part 3 of this series to you in another response, but the first example in here discusses such an optimization that GCC did which removed security checks in the Linux kernel (see also this series -- look down at "A Fun Case Analysis")
GCC has long turned on -fno-strict-aliasing because optimizations based on the strict aliasing assumption break the kernel (more precisely: code that violates the standard's strict aliasing rules was being "mis-"optimized), though I don't know if it led to security implications
C/C++ leaves a wide are undefined to support oddball system architectures. For example, if you have some memory that only can store floating point numbers, and some general-purpose memory, the address ranges might overlap - that's why pointer subtraction is undefined unless within an array. In practice most programmers can treat all memory as one contiguous byte array, but on special-purpose hardware you can still use C. Most of C's undefined behavior comes from the much wider variety of system architectures when C was young, but can still be useful for embedded systems.
That's an awfully narrow description of the kinds of behaviors that are undefined in C and C++. Here's an incomplete list of actions that will provoke undefined behavior in C++ off the top of my head, all of which are perfectly relevant and possible to accidentally do on every-day desktop architectures:
Defining an object with the same name in two different compilation units with different definitions (violation of the ODR)
Signed integer overflow (props to some people elsewhere in the thread that taught me that this isn't true for unsigned!)
Writing or reading past the end or beginning of an array
Dereferencing a NULL pointer
Accessing an object of one type via a pointer of another type (violating the strict-aliasing rules)
Not 100% positive, but I believe using a name reserved for implementations: that is any name globally beginning with an underscore followed by a capital letter, or containing two consecutive underscores, or something else I can't remember
Accessing memory at an address that has been free()ed or deleted
Assigning the same scalar value twice without an intervening sequence point (e.g. i = i++; not only doesn't have a well-defined evaluation order but also provokes undefined behavior entirely)
Calling several STL algorithms with iterator pairs that don't form a valid range, e.g. copy(vec1.begin(), vec2.begin(), vec1.end()) (I think I ordered those right)
Of course it is, and it is supposed to be able to do so.
Actually no, you're not, or you're programming in Some-C-Like-Language and not C. In C, dereferencing a NULL pointer is always undefined behavior, and compilers are allowed (though presumably very unlikely to on embededd platforms) to make transformations based on that assumption, such as the following:
void f(int * p) {
int x = *p;
if (p == NULL) {
g();
} }
C compilers are allowed to optimize away the null check and subsequent call to g(), and if you rely them not, you're relying on behavior that's not guaranteed by the standard.
This seems like a GCC bug (assuming no overflow). Why are all compilers being blamed?
It's not a bug, and they're not blaming anyone. All compilers perform safe-but-unsafe transformations based on undef-behavior assumptions. You just have to pick a study target.
OK, if the spec says that a is undefined after the call to realloc, then IMHO the compiler should change the type of a from char * to UNDEFINED and complain. Based on what you're saying, it sounds like Clang is wrong. It sounds like they're treating undefined behavior as implementation defined behavior.
I'm sure somebody will correct me if I'm wrong on that one.
You're wrong on that one.:-)
First, let's start with this specific case. First of all, the type of a variable can't "change", because the type of a variable in languages without type-state sutff is static. (Aside: this is a useful way to think about the distinction between statically typed languages and dynamically typed ones -- in statically typed languages, variables have types, while in dynamically typed languages, values have "types.") In this case it's pretty easy to see how the compiler can deal with it, but in general it's not:
char * b; if (big_fancy_condition) {
b = realloc(a,...) } .... if (another_big_fancy_condition) { ... *b...; }
Can that program provoke undefined behavior? Depends on the conditions, which means it's undecidable in general. In the type viewpoint, what's the type during the ellipsis? Is it char* or is it inaccessible? It's char* down one branch but inaccessible down the other, and there's not a fully-general way to merge those two types (in a way that type-checking is still decidable).
Second, undefined behavior means the compiler is allowed to do anything -- it's less restrictive than implementation-defined. For implementation-defined behavior, the compiler needs to make a choice, stick with it (at least with a consistent set of compiler settings), and document it. For undefined behavior, the compiler can do anything it wants to, for any reason it wants to, can do different things in the same situation in different places because why the hell not, etc. -- the standard imposes no restrictions on what happens once undefined-behavior is triggered. See here for more.
The first mistake was using signed integers. unsigned integers always have well-defined overflow (modulo semantics), which means it's easier to construct safe conditionals
Not in C and C++ they don't. The compiler is allowed to perform that optimization with either signed or unsigned integers.
BTW, I should also say that the summary doesn't do a very good job conveying this. That compilers remove security-sensitive code in some situations has been known for more than a decade (I know off the top of my head how to establish 2002, but probably long before that), but the article is written for people who don't necessarily know that, and it can't start from very little and build up to "here's what their improvement actually was."
Just because PC Lint could find a small number of potential bugs doesn't mean it's a solved problem by any means. Program analysis is still pretty crappy in general, and they made another improvement, just like tons of people before them, PC Lint before them, and tons of people before PC Lint.
Didn't RTFA because this is/., but I'd guess that it's code that works now but is fragile under a change of compiler, compiler version, optimization level, or platform.
Besides, isn't it ultimately the Judge who determines the sentence, not the jury? Maybe it varies on the type of case and such but my point is the same.
Many places in the US require a jury to affirm a capital sentence.
I don't know what the deal is in full with that -- whether that's because it's considered Constitutionally-mandated, whether you need unanimous agreement, how common that is, etc. -- but the death penalty is a special case (and it's also the only case discussed here).
They don't have anything in the cheap $400 range because they don't make cheap.
They don't have anything (IMO) for the enthusiast desktop user. The iMacs are inappropriate for a few reasons, and Mac Pros are too expensive.I'd consider them for a laptop purchase, but in the desktop space they don't have anything that's remotely reasonable.
verb [with object] help the progress or development of (something); promote: he had depended on using them to further his own career
Origin:
Old English furthor (adverb), furthra (adjective), fyrthrian (verb)
oxforddictionaries.com
Unfortunately I don't have access to the OED any more so don't know places where I can get dated citations of use, but it's a good thing you don't have to believe in facts for them to be true.
A release is needed if the person is the primary subject of the photo/i.
Also not completely true. Whether a release is needed is a balancing act between First Amendment principles and privacy principles. Things like newsworthyness move the balance toward "allowed even without a model release" (how successful do you think a criminal who was captured on surveillance cameras would be at suing a news program that showed footage of their robbery because the program didn't have a model release?) and commercial use and especially implying endorsement push it toward "model release needed". (These are merely examples, there are other aspects that the courts would consider.)
Pick any top-tier CS conference. They'll probably have something there.
For example, OSDI '12 (MSR personnel on 5 papers, 2 of which all coauthors worked at MSR), PLDI 2012 (MSR personnel on 6 papers), SIGGRAPH 2013 (harder to sort through, but I count 16 papers with at least one MSR co-author), VLDB 2011 (8 research papers as well as several other things like demos, a keynote, an industrial paper, and a 10-year-retrospective best paper award), STOC 2013 (16 papers if I counted right!), etc.
Seriously, I was not being choosy with those conferences -- the only choosy things I did was pick years for which there was an obvious page that listed the institutions with the authors instead of just the authors (e.g. VLDB 2013) because I'm lazy. If you pick a conference that covers a topic of interest, MSR has had something there.:-)
MS Research is not a typical R&D department. It's much more along the lines of something like Bell Labs than anything else. The only other industry research lab that even comes close to MSR currently is IBM's.
If a game is designed so that your fingers regularly need to travel over more than the 15 or so buttons on a console controller, something is just wrong. All the context and modal menus present in console games aren't just to minimize the number of shortcut buttons needed, it's good design.
That's a really narrow view. Take something like an RTS. In Starcraft, you've got 10 unit group hotkeys and 3 or 4 (depending on SC1 or SC2) location hotkeys. High level play will use most or all of them. Add to that the 10 or so keys for actual commands and you're well over your key allotment.
Heck, while I'm not your typical player, I even have 15 different functions that I bound to keys in Portal.
The real issue with mouse vs. thumbstick/trackpad accuracy has little to do with the resolution.
I think a very good case could be made that the biggest difference is between relative and absolute positioning, and Valve says they solved that by making their controller allow absolute positioning.
Suppose I want to move my view from direction A to direction B. On the PC, I have to learn how far to move my mouse. It doesn't matter how quickly or slowly I move it*, it will always go to the same place. If I need to do it very quickly and lose some accuracy, I do the same thing as if I need accuracy but not speed, just faster.
(* Well, if you turn off mouse acceleration. But even if you don't, what I say is still way more true of mouse/keyboard than it is of controller.)
Contrast with a controller, where there's a timing aspect. You have to point the stick in the direction you want and hold it there for a certain time. If you prefer speed to accuracy, you don't just do the same thing quicker than if you prefer accuracy to speed, because you actually have to move the thumbstick further to swing over.
And a related problem is that the thumbstick has to balance between allowing fine control and also wild swings -- and if you want to be able to swing around faster than your controller and settings allow, you can't. With absolute positioning, you have to be going really damn fast before you can't go faster.
As someone who as a rule hates controllers and passed by this announcement for awhile, I'm actually fairly excited after reading through. Cautiously excited, because I'm not convinced of the resolution question, your point, or how for a game like an RTS or 4X how well the circular control maps to the rectangular screen. But I will definitely be checking it out.
Buttons and Joysticks have an advantage touchpads and pushy circles lack: Nuanced tactile response. I can *feel* which direction I have the joystick jammed, with an accuracy of several degrees.
I can flip that around though: it sounds like the design of their trackpad has something huge that controllers lack, which is absolute positioning. Suppose you are looking in direction A and want to look in direction B. With a controller, you have to push the thumbstick in the direction of B and get the timing right in relation to amount of tilt. With the Steam Controller, it sounds like it's much more like a mouse: it's not based on timing at all*, and all you have to learn is the distance of thumb movement that corresponds to the distance on the screen.
* There is mouse acceleration on the computer if you don't turn it off, so that's not quite true, but it's way more true than on a traditional controller.
If my understanding and the above analysis is correct, IMO this is potentially huge. I don't really game on consoles because I more or less can't use controllers. There's a bit of a personal feedback loop there in that I don't play on consoles and so I don't get practice with them and so I suck at them and so I don't play on them, but this seems to be a pretty objective fact as well -- mouse and keyboard are basically universally more accurate for aiming in things like FPSs, and they make much more complex and fast RTS manipulations possible as well. I'm actually fairly excited to be able to try this, because I think it's probably the controller that I am most likely to be able to use.
P.S. Isn't Steam Engine a better name than Steam Box?
Clever and I do like it, but I suspect they might want to be careful to avoid confusion with things like the Source engine (and the idea of a game engine in general). May not matter for everyone, but probably would matter for some. (Might cause more problems the other way around -- people hear about Valve's "Steam Engine", and later hear about their "Source Engine" and get confused as they're looking around for it. Or probably even worse: they look for "Valve's Engine" or something and come up with stuff about Source rather than the Steambox.)
Slashdot Mirror
You probably haven't used any desktop compilers.
Just a sampling:
That's an awfully narrow description of the kinds of behaviors that are undefined in C and C++. Here's an incomplete list of actions that will provoke undefined behavior in C++ off the top of my head, all of which are perfectly relevant and possible to accidentally do on every-day desktop architectures:
I'm lazy so I'll stop typing now.
This blog post explains why they can't always warn about it.
Of course it is, and it is supposed to be able to do so.
Actually no, you're not, or you're programming in Some-C-Like-Language and not C. In C, dereferencing a NULL pointer is always undefined behavior, and compilers are allowed (though presumably very unlikely to on embededd platforms) to make transformations based on that assumption, such as the following:
C compilers are allowed to optimize away the null check and subsequent call to g(), and if you rely them not, you're relying on behavior that's not guaranteed by the standard.
This seems like a GCC bug (assuming no overflow). Why are all compilers being blamed?
It's not a bug, and they're not blaming anyone. All compilers perform safe-but-unsafe transformations based on undef-behavior assumptions. You just have to pick a study target.
I was already responding, but yes, your summary sounds pretty much perfect.
OK, if the spec says that a is undefined after the call to realloc, then IMHO the compiler should change the type of a from char * to UNDEFINED and complain. Based on what you're saying, it sounds like Clang is wrong. It sounds like they're treating undefined behavior as implementation defined behavior.
I'm sure somebody will correct me if I'm wrong on that one.
You're wrong on that one. :-)
First, let's start with this specific case. First of all, the type of a variable can't "change", because the type of a variable in languages without type-state sutff is static. (Aside: this is a useful way to think about the distinction between statically typed languages and dynamically typed ones -- in statically typed languages, variables have types, while in dynamically typed languages, values have "types.") In this case it's pretty easy to see how the compiler can deal with it, but in general it's not:
Can that program provoke undefined behavior? Depends on the conditions, which means it's undecidable in general. In the type viewpoint, what's the type during the ellipsis? Is it char* or is it inaccessible? It's char* down one branch but inaccessible down the other, and there's not a fully-general way to merge those two types (in a way that type-checking is still decidable).
Second, undefined behavior means the compiler is allowed to do anything -- it's less restrictive than implementation-defined. For implementation-defined behavior, the compiler needs to make a choice, stick with it (at least with a consistent set of compiler settings), and document it. For undefined behavior, the compiler can do anything it wants to, for any reason it wants to, can do different things in the same situation in different places because why the hell not, etc. -- the standard imposes no restrictions on what happens once undefined-behavior is triggered. See here for more.
Not in C and C++ they don't. The compiler is allowed to perform that optimization with either signed or unsigned integers.
I take back this statement... it is not correct, at least in C99.
The first mistake was using signed integers. unsigned integers always have well-defined overflow (modulo semantics), which means it's easier to construct safe conditionals
Not in C and C++ they don't. The compiler is allowed to perform that optimization with either signed or unsigned integers.
BTW, I should also say that the summary doesn't do a very good job conveying this. That compilers remove security-sensitive code in some situations has been known for more than a decade (I know off the top of my head how to establish 2002, but probably long before that), but the article is written for people who don't necessarily know that, and it can't start from very little and build up to "here's what their improvement actually was."
Don't worry, the authors know what they're doing.
Just because PC Lint could find a small number of potential bugs doesn't mean it's a solved problem by any means. Program analysis is still pretty crappy in general, and they made another improvement, just like tons of people before them, PC Lint before them, and tons of people before PC Lint.
Didn't RTFA because this is /., but I'd guess that it's code that works now but is fragile under a change of compiler, compiler version, optimization level, or platform.
Flawless software exists. NASA can do it...
But not always, even when they try. The LEM had a couple of bugs that made the Apollo 11 landing even more dicey than it would have otherwise been. Mars Pathfinder had a priority inversion bug that caused software resets. And of course the Mars Climate Observer was lost because of its famous metric vs imperial unit mixup.
And those are just the ones that I know about.
Besides, isn't it ultimately the Judge who determines the sentence, not the jury? Maybe it varies on the type of case and such but my point is the same.
Many places in the US require a jury to affirm a capital sentence.
I don't know what the deal is in full with that -- whether that's because it's considered Constitutionally-mandated, whether you need unanimous agreement, how common that is, etc. -- but the death penalty is a special case (and it's also the only case discussed here).
The models were randomly arranged and it was like "if you want the sunroof, you have to get the leather seats" with cars
Wat? To my "PC"- and desktop-byased eyes, Apple has those kinds of things all over the place:
I love how people don't price in size, weight, or battery life. Those things are free, right?
They aren't free, but for lots of people they're less expensive than money.
They don't have anything in the cheap $400 range because they don't make cheap.
They don't have anything (IMO) for the enthusiast desktop user. The iMacs are inappropriate for a few reasons, and Mac Pros are too expensive.I'd consider them for a laptop purchase, but in the desktop space they don't have anything that's remotely reasonable.
oxforddictionaries.com
Unfortunately I don't have access to the OED any more so don't know places where I can get dated citations of use, but it's a good thing you don't have to believe in facts for them to be true.
A release is needed if the person is the primary subject of the photo/i.
Also not completely true. Whether a release is needed is a balancing act between First Amendment principles and privacy principles. Things like newsworthyness move the balance toward "allowed even without a model release" (how successful do you think a criminal who was captured on surveillance cameras would be at suing a news program that showed footage of their robbery because the program didn't have a model release?) and commercial use and especially implying endorsement push it toward "model release needed". (These are merely examples, there are other aspects that the courts would consider.)
Can you show some examples of Microsoft research?
Pick any top-tier CS conference. They'll probably have something there.
For example, OSDI '12 (MSR personnel on 5 papers, 2 of which all coauthors worked at MSR), PLDI 2012 (MSR personnel on 6 papers), SIGGRAPH 2013 (harder to sort through, but I count 16 papers with at least one MSR co-author), VLDB 2011 (8 research papers as well as several other things like demos, a keynote, an industrial paper, and a 10-year-retrospective best paper award), STOC 2013 (16 papers if I counted right!), etc.
Seriously, I was not being choosy with those conferences -- the only choosy things I did was pick years for which there was an obvious page that listed the institutions with the authors instead of just the authors (e.g. VLDB 2013) because I'm lazy. If you pick a conference that covers a topic of interest, MSR has had something there. :-)
MS Research is not a typical R&D department. It's much more along the lines of something like Bell Labs than anything else. The only other industry research lab that even comes close to MSR currently is IBM's.
If a game is designed so that your fingers regularly need to travel over more than the 15 or so buttons on a console controller, something is just wrong. All the context and modal menus present in console games aren't just to minimize the number of shortcut buttons needed, it's good design.
That's a really narrow view. Take something like an RTS. In Starcraft, you've got 10 unit group hotkeys and 3 or 4 (depending on SC1 or SC2) location hotkeys. High level play will use most or all of them. Add to that the 10 or so keys for actual commands and you're well over your key allotment.
Heck, while I'm not your typical player, I even have 15 different functions that I bound to keys in Portal.
The real issue with mouse vs. thumbstick/trackpad accuracy has little to do with the resolution.
I think a very good case could be made that the biggest difference is between relative and absolute positioning, and Valve says they solved that by making their controller allow absolute positioning.
Suppose I want to move my view from direction A to direction B. On the PC, I have to learn how far to move my mouse. It doesn't matter how quickly or slowly I move it*, it will always go to the same place. If I need to do it very quickly and lose some accuracy, I do the same thing as if I need accuracy but not speed, just faster.
(* Well, if you turn off mouse acceleration. But even if you don't, what I say is still way more true of mouse/keyboard than it is of controller.)
Contrast with a controller, where there's a timing aspect. You have to point the stick in the direction you want and hold it there for a certain time. If you prefer speed to accuracy, you don't just do the same thing quicker than if you prefer accuracy to speed, because you actually have to move the thumbstick further to swing over.
And a related problem is that the thumbstick has to balance between allowing fine control and also wild swings -- and if you want to be able to swing around faster than your controller and settings allow, you can't. With absolute positioning, you have to be going really damn fast before you can't go faster.
As someone who as a rule hates controllers and passed by this announcement for awhile, I'm actually fairly excited after reading through. Cautiously excited, because I'm not convinced of the resolution question, your point, or how for a game like an RTS or 4X how well the circular control maps to the rectangular screen. But I will definitely be checking it out.
Buttons and Joysticks have an advantage touchpads and pushy circles lack: Nuanced tactile response. I can *feel* which direction I have the joystick jammed, with an accuracy of several degrees.
I can flip that around though: it sounds like the design of their trackpad has something huge that controllers lack, which is absolute positioning. Suppose you are looking in direction A and want to look in direction B. With a controller, you have to push the thumbstick in the direction of B and get the timing right in relation to amount of tilt. With the Steam Controller, it sounds like it's much more like a mouse: it's not based on timing at all*, and all you have to learn is the distance of thumb movement that corresponds to the distance on the screen.
* There is mouse acceleration on the computer if you don't turn it off, so that's not quite true, but it's way more true than on a traditional controller.
If my understanding and the above analysis is correct, IMO this is potentially huge. I don't really game on consoles because I more or less can't use controllers. There's a bit of a personal feedback loop there in that I don't play on consoles and so I don't get practice with them and so I suck at them and so I don't play on them, but this seems to be a pretty objective fact as well -- mouse and keyboard are basically universally more accurate for aiming in things like FPSs, and they make much more complex and fast RTS manipulations possible as well. I'm actually fairly excited to be able to try this, because I think it's probably the controller that I am most likely to be able to use.
P.S. Isn't Steam Engine a better name than Steam Box?
Clever and I do like it, but I suspect they might want to be careful to avoid confusion with things like the Source engine (and the idea of a game engine in general). May not matter for everyone, but probably would matter for some. (Might cause more problems the other way around -- people hear about Valve's "Steam Engine", and later hear about their "Source Engine" and get confused as they're looking around for it. Or probably even worse: they look for "Valve's Engine" or something and come up with stuff about Source rather than the Steambox.)