@JoshRoss: I don't think that alone would suffice: repelling water is great, but it doesn't take a very large droplet to short a USB connector. I just hope they didn't overuse the ugly silicone plug covers.
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...
I don't recall, honestly, and I don't have a copy of VB to test it out. Anyway, the only documentation I could find seems to indicate that that was not the intended behavior anyway.
As for C, no, it never behaved that way. C maps the case labels (which must be integer constants) in jump tables and obviously throws a fit if one of the labels is duplicated.
Just out of curiosity, I cannot figure out the advantage of using that particular artifact. Care to elaborate?
There isn't an exact number as not all the XP users are using the same bits. I'd say that the majority run XP SP3, so that's roughly three years. Much less if you consider security patches which I don't see a good reason to brush off lightly.
As about the rest of your post, I must have misunderstood you somewhere along the lines... it seems you went from claiming that we would get to use Microsoft software for free to some other company maintaining it (for free, of course) to this just being a temporary measure until everybody takes the open platform pill (which is also a painless, quick and inexpensive process).
Unless someone uncovered a technology or a spell that makes huge costs dissolve, that would be a bloodbath, but you know that.