Hey, I thought nobody was supposed to comment on Windows 8 until build.
//TODO: find an appropriate smiley
Loading User Information from Channel 9
Something went wrong getting user information from Channel 9
Loading User Information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
Maybe Apple feared back compatibility. Lots of programmers have written incredibly bad code when checking for version numbers, maybe because they don't think their application will stay around long enough, or because they don't think they will still be around when the excrement hits the ventilation system. Or something... but historically, bumping up the major version number has proved to be a big source of headaches.
Obviously. And using C would still expose you to the subtle difference between eager and short-circuit operators... unfortunately mine wasn't an academic example.
As for the other comment, I think the hash function has little to do with what blowdart was referring to. If you use a method that fails early (such as short-circuit evaluation, or even just memcmp) when comparing some secret value with another submitted by the attacker, you may be giving away how much of the submitted value is correct. It's the same as making a combination lock that emits a louder tick whenever you hit on a partial result.
In the end, someone may cry, but it won't necessarily be a cryptographer.
@exoteric: It's a minefield. WHQL may be imperfect, but there are two things that keep everybody reasonably happy: it's perceived as a level field and failures are not publicly disclosed. Neither condition would ever be possible with a public beta and things would get ugly real quick.
@androidi: no, it's the job of Nvidia to write a driver that performs as it should. What WHQL is all about is making sure that a bad driver doesn't cause a blue screen. Performance is none of their concerns.
And even if it were, they may not get their job done: hardware manufacturer will go to extreme lengths to beat the competition while passing WHQL with flying colors... there's an old post by Raymond Chen on the subject. Recommended read.
That was my point exactly. By using & instead of &&, either you are wasting time, or your code relies on obscure side-effects. Neither is desirable, unless you are dealing with...
This is a legitimate case where short-circuiting is undesirable, and that can also happen elsewhere (for instance, time sensitive code in firmware). Yet, in these cases I prefer not to rely on a subtle difference and express my intent more clearly. Maintenance happens.
@spivonious: That's another area of problem when switching between languages as unlike C# in C/PHP/Python .. "&" operator is bit wise operator ... hence I normally use the generic C like operators in most of the languages following C like syntax viz. Java, PHP, partly Python ... here vb.net is easier as the confusion between operator is minimum due to its own unique syntax ...
Actually, for all practical purposes the semantics of & are the same in C and C#.
Not that it matters much; there shouldn't be a good reason to prefer & to the short-circuiting && when dealing with boolean values (and when there is, your code probably contains a problem waiting to happen).
@davewill: after some testing, it seems that all this is caused by the fact that IE treats <br> within a <pre> inconsistently: they get honored for rendering, but ignored when the text content is extracted. This doesn't happen for <br>'s outside a <pre>, nor when the RTF and HTML contents of the clipboard are generated. This explains why this happens for Notepad (that looks at the text content of the clipboard) but not for Wordpad (which prefers RTF).
So, it would seem to be IE's faut... but even the prettifier used by StackOverflow deserves some kicking: it seems it replaces line breaks with <br> and every second blank with . Which makes the <pre> useless and introduces the problem in IE (IE is perfectly happy with line breaks in a <pre>, or <br> outside a <pre> and would work fine with the <pre> block you can see in the page source). A job well done, no doubt.
As to Visual Studio, it's innocent of all this mess. It finds the text content in the clipboard and uses that, period. And it's a good thing it does just that... imagine what would happen if it detected the presence of HTML code in the clipboard and tried to be smart about it: it would probably just fire up MSHTML, convert the HTML to text and paste that. Which would have the only effect of making the other browsers work the same as IE. Oops...