Except your argument has been proven false - many eyes DID catch the bug!
No they didn't. Many eyes missed it for 9 years. It was caught because of the bow-wave following Apple's discovery of a similar bug in their code. A bug that had existed in their code for 18 months. As a result, one pair of eyes, finally took a look at this long standing open source code and found the bug.
Linus's law "many eyes make all bug shallow" is horse-shit.
You state this falsehood while at the same time argue the only process that "works" is one where not only would this bug have been around for a decade
Except that the equivalent bug was found in Apple's code, by Apple, in 18 months. Not 10 years. That's 18 months too long, but still 7.5 years faster than it was found in GnuTLS.
OK. But that's quite a different and lesser claim to Linus's Law: "given enough eyeballs, all bugs are shallow".
It's this idea, that Open Source is by nature less defective, because more people are looking at the source, that's shown itself to be completely wrong over the years, and especially with this example.
What would that look like though. You keep asserting philosophy that's not backed by anything practical. If you have 97 levels of indention, nothing is obvious.
In other answers to you I've already given you two practical alternatives. Exceptions, and a way to refactor nested ifs.
Microsoft C has
I've also pointed out that this sub-discussion is predicated on what you would do with a language that was eschewing the goto. Such a structured language would already have the necessary structures, so the question of what to do with legacy languages such as C is irrelevant. That C is a bad tool with which you have to emulate some control structures with gotos is no defense of gotos in modern languages.
My point to GP was that Bitcoin is already regulated at least as much as cash is.
Which I why I referred to Bureaux de Changes (turns out you guys call them "Currency Exhcanges"), not Forex. But either way, they are regulated where Bitcoin is not.
Bullshit. One of the projects at my last job had a single function in C++ that was over 50 printed pages. 5-deep nested loops, not even counting conditionals
I don't care. "spaghetti code" was coined as an antonym to "structured code". Deeply nested but otherwise structured code may be on need of refactoring, but it is not spaghetti, by definition.
You might want to read "Considered Harmful" Essays Considered Harmful.
Which says absolutely nothing about gotos. Thats a classic strawman, since you are the one that brought up "considered harmful" not me.
Just because *you* don't understand when to properly use a construct doesn't make the construct evil or wrong.
I was programming before the term "structured programming" even came into general use. When all we had was gotos. I learned structured coding and later OOP as they developed. That's how long I've been doing this stuff. There's no lack of understanding on this end of the exchange. And that part of your argument was an ad-hominem.
Strawman and ad-homoinem in the same post. Classic poor argumentation,
Sure, but the reason for goto:clanup specifically is "ease of code review". You want to make it easy to demonstrate that every open has a matching close, every alloc has a matching free, and so on. WHen the code base end up with 1000 allocs and 999 frees, the faster and easier you can spot the matching bookends, the better.
And the falseness of that argument is demonstrated by the fact that it's exactly this pattern that has disguised the bugs in the TLS code for Apple for 18 months and GnuTLS for 9 years. The simplicity is superficial. In fact the goto is a huge source of bugs that are not apparent in code reviews.
If the code was written in a structured form these bugs would likely not have happened, or would at least have been more obvious in code review.
The linux kernel is full of gotos. Assembly is bereft blocks and that sort of structure. So "goto" isn't the source of all evil.
That there are primitive languages that don't have proper control structures isn't an argument. It's pointing out the obvious that when there's a limited tool, one needs to make do. Goto is needed to jerry-rig control structures when they are not there. When there's a full set of control structures they are not needed.
if (pt1 = generate_first()) {
There are even bigger problems than the goto in the code you wrote. Assignment in the condition of an if statement? Heck most compilers would issue a warning for even writing such a nasty thing.
So take the simple example and imagine you are building something complex like a network request with data and metadata buffers and the actual request structure itself et al... as the number of parts grow the number of bizarre else conditions you have to use to do stepwise cleanup become bothersome repetitions of code.
The use case and approach you describe is exactly why these errors in TLS libraries have laid undiscovered for so long. So the argument that they simplify is demonstrably wrong. The simplicity is superficial. In reality they lead to assumptions that wouldn't be made with properly structured code.
I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.
Humpty Dumpty said "When I use a word, it means just what I choose it to meanâ"neither more nor less." The rest of us try to stick with the established uses of words and phrases.
The term "spaghetti code" was coined as the antonym of "structured code". Deeply nested but nevertheless structured code is not spaghetti code.
Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if.... return statements.
Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox)
Exceptions aren't really unstructured. Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
The main problem with early exits is using them in C.
Right, but this section of the discussion was under the condition: "if you are taking the step to remove gotos from a language...". Yes, C is old fashioned, and it's lack of exceptions calls for emulating them with gotos or early returns. But that's not the topic.
It does amuse me of people who don't understand modern compiler optimisations try to be clever. The biggest lesson you can learn is "don't optimise prematurely".
Wow, have you ever actually written production code? Just wow.
More than 30 years of it. And the code you show is common, but that doesn't make it ideal. Big Macs are common, and easy food for the lazy, but that doesn't make it good food,
The problem with it is that it gets buried in a sizeable function, then a bit of code that is needed in every case is added before the final return. It seems to work, and may even pass superficial testing, because the bug only shows under error conditions.
This is a common bug that all too often gets into shipping software. (But not mine).
Substitute "throw new ERROR(..)" or "goto:error" depending on what kind of code your writing, it's the same thing any way you do it.
No, it's entirely different, because there is a "finally" section that ensures that "always needs to run" code really does get run. This is the correct way to do it. Exceptions are a real control structure, not a misuse of a goto equivalent.
Of course you may argue that the former pattern is needed for languages such as C that don't support exceptions. But then that would be a comprehension error on your part, as this part of the discussion was about "A language that takes the step to rule out gotos".
Now I don't know whether this is a case of downloading a few pictures to test the filtering system (or to work out how easy it was to do), or whether this was a large stockpile that went beyond any notion of research. But frankly, if anyone could possibly use the old "research" excuse it would have to be someone that actually had a need to do research.
He was in the position where he would be in no doubt that such "research" would be illegal.
If there is a need for such research one would expect it to be done in a specialist facility, under supervision, and with proper monitoring, and for there to be a provision in the law to allow for that.
Yeah, force people to write a big pile of nested bracket spaghetti...
1. "nested brackets" (blocks) are by definition not spaghetti. Spaghetti is exclusively the result of gotos and their control equivalents (like the early return).
2. Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
No the issue was with conditionals and braces. The same issue would have happened even if it were two return statements.
And a return statement before the end of a function is essentially a goto. A language that takes the step to rule out gotos should also not allow early returns.
Apple had their goto bug in TLS for about 18 months before they spotted it.
GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.
OK, exchanges are more like bureaux de changes. And bureaux de changes are also subject to banking system regulation So it comes to the same: regulated vs unregulated.
Digression: Remember the Apple SSL security bug last week? How it was relished by open source types with talk of open source having "many eyes making all bugs shallow". Well it turns out that Linux and every other OS relying on GnuTLS has had a similar security bug since 2005.
And then, how many people are keeping the bitcoins themselves without adequate off-site backup?
In the general population maybe 5% of people have off site backups. Do they suddenly become wiser when they have bitcoins? Maybe a bit. But I'll bet it's still far less than half that have a proper backup system.
It's not just trust. It's also regulation and associated official compensation schemes. That's what makes for a real banking system. And what is lacking in Bitcoin.
Occam's Razor says, even if there was no governmental or corporate involvement in the heist, they won't bend over backwards to help the victims recover their losses, and just may be quietly cheering on the 'thieves' from the sidelines.
You say it like it's a bad thing. One of the objectives of bitcoin users is to avoid paying tax. And yet you believe governments should "bend over backwards" to help cover the inevitable losses from an unregulated market? Covered presumably by the tax paid by people using ordinary currencies.
Apple's site lists a number of third party apps with CarPlay functionality and promises more to come.
Ah, I missed those. But I'd guess it's specific partnerships, rather than an open App Store like arrangement.
And to the GP, mirroring is a terrible idea - not only because a car's built-in display will almost certainly have a different aspect ratio and resolution, but because an interface designed for use in a car is (should be) different in some ways to that of a phone (even more streamlined, simplified, and with larger fonts).
Yes, straight mirroring would be bad. But Airplay already allows iOS video out devices to be different resolutions and to display different contents from the built in screen. So presumably no problem there.
Slashdot Mirror
Except your argument has been proven false - many eyes DID catch the bug!
No they didn't. Many eyes missed it for 9 years. It was caught because of the bow-wave following Apple's discovery of a similar bug in their code. A bug that had existed in their code for 18 months. As a result, one pair of eyes, finally took a look at this long standing open source code and found the bug.
Linus's law "many eyes make all bug shallow" is horse-shit.
You state this falsehood while at the same time argue the only process that "works" is one where not only would this bug have been around for a decade
Except that the equivalent bug was found in Apple's code, by Apple, in 18 months. Not 10 years. That's 18 months too long, but still 7.5 years faster than it was found in GnuTLS.
OK. But that's quite a different and lesser claim to Linus's Law: "given enough eyeballs, all bugs are shallow".
It's this idea, that Open Source is by nature less defective, because more people are looking at the source, that's shown itself to be completely wrong over the years, and especially with this example.
What would that look like though. You keep asserting philosophy that's not backed by anything practical. If you have 97 levels of indention, nothing is obvious.
In other answers to you I've already given you two practical alternatives. Exceptions, and a way to refactor nested ifs.
Microsoft C has
I've also pointed out that this sub-discussion is predicated on what you would do with a language that was eschewing the goto. Such a structured language would already have the necessary structures, so the question of what to do with legacy languages such as C is irrelevant. That C is a bad tool with which you have to emulate some control structures with gotos is no defense of gotos in modern languages.
My point to GP was that Bitcoin is already regulated at least as much as cash is.
Which I why I referred to Bureaux de Changes (turns out you guys call them "Currency Exhcanges"), not Forex. But either way, they are regulated where Bitcoin is not.
http://en.wikipedia.org/wiki/F...
They HAVE to be regulated, most obviously because they are the most obvious channel for money laundering.
Huh? How so?
Given the lack of circumspection considering the accusations you wildly make about climate scientists, I don't think so.
Bullshit. One of the projects at my last job had a single function in C++ that was over 50 printed pages. 5-deep nested loops, not even counting conditionals
I don't care. "spaghetti code" was coined as an antonym to "structured code". Deeply nested but otherwise structured code may be on need of refactoring, but it is not spaghetti, by definition.
You might want to read "Considered Harmful" Essays Considered Harmful.
Which says absolutely nothing about gotos. Thats a classic strawman, since you are the one that brought up "considered harmful" not me.
Just because *you* don't understand when to properly use a construct doesn't make the construct evil or wrong.
I was programming before the term "structured programming" even came into general use. When all we had was gotos. I learned structured coding and later OOP as they developed. That's how long I've been doing this stuff. There's no lack of understanding on this end of the exchange. And that part of your argument was an ad-hominem.
Strawman and ad-homoinem in the same post. Classic poor argumentation,
Sure, but the reason for goto :clanup specifically is "ease of code review". You want to make it easy to demonstrate that every open has a matching close, every alloc has a matching free, and so on. WHen the code base end up with 1000 allocs and 999 frees, the faster and easier you can spot the matching bookends, the better.
And the falseness of that argument is demonstrated by the fact that it's exactly this pattern that has disguised the bugs in the TLS code for Apple for 18 months and GnuTLS for 9 years. The simplicity is superficial. In fact the goto is a huge source of bugs that are not apparent in code reviews.
If the code was written in a structured form these bugs would likely not have happened, or would at least have been more obvious in code review.
The linux kernel is full of gotos. Assembly is bereft blocks and that sort of structure. So "goto" isn't the source of all evil.
That there are primitive languages that don't have proper control structures isn't an argument. It's pointing out the obvious that when there's a limited tool, one needs to make do. Goto is needed to jerry-rig control structures when they are not there. When there's a full set of control structures they are not needed.
if (pt1 = generate_first()) {
There are even bigger problems than the goto in the code you wrote. Assignment in the condition of an if statement? Heck most compilers would issue a warning for even writing such a nasty thing.
So take the simple example and imagine you are building something complex like a network request with data and metadata buffers and the actual request structure itself et al... as the number of parts grow the number of bizarre else conditions you have to use to do stepwise cleanup become bothersome repetitions of code.
The use case and approach you describe is exactly why these errors in TLS libraries have laid undiscovered for so long. So the argument that they simplify is demonstrably wrong. The simplicity is superficial. In reality they lead to assumptions that wouldn't be made with properly structured code.
I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.
Humpty Dumpty said "When I use a word, it means just what I choose it to meanâ"neither more nor less." The rest of us try to stick with the established uses of words and phrases.
The term "spaghetti code" was coined as the antonym of "structured code". Deeply nested but nevertheless structured code is not spaghetti code.
Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if .... return statements.
Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
http://www.drdobbs.com/archite...
You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox)
Exceptions aren't really unstructured. Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
The main problem with early exits is using them in C.
Right, but this section of the discussion was under the condition: "if you are taking the step to remove gotos from a language...". Yes, C is old fashioned, and it's lack of exceptions calls for emulating them with gotos or early returns. But that's not the topic.
It does amuse me of people who don't understand modern compiler optimisations try to be clever. The biggest lesson you can learn is "don't optimise prematurely".
Wow, have you ever actually written production code? Just wow.
More than 30 years of it. And the code you show is common, but that doesn't make it ideal. Big Macs are common, and easy food for the lazy, but that doesn't make it good food,
The problem with it is that it gets buried in a sizeable function, then a bit of code that is needed in every case is added before the final return. It seems to work, and may even pass superficial testing, because the bug only shows under error conditions.
This is a common bug that all too often gets into shipping software. (But not mine).
Substitute "throw new ERROR(..)" or "goto :error" depending on what kind of code your writing, it's the same thing any way you do it.
No, it's entirely different, because there is a "finally" section that ensures that "always needs to run" code really does get run. This is the correct way to do it. Exceptions are a real control structure, not a misuse of a goto equivalent.
Of course you may argue that the former pattern is needed for languages such as C that don't support exceptions. But then that would be a comprehension error on your part, as this part of the discussion was about "A language that takes the step to rule out gotos".
Now I don't know whether this is a case of downloading a few pictures to test the filtering system (or to work out how easy it was to do), or whether this was a large stockpile that went beyond any notion of research. But frankly, if anyone could possibly use the old "research" excuse it would have to be someone that actually had a need to do research.
He was in the position where he would be in no doubt that such "research" would be illegal.
If there is a need for such research one would expect it to be done in a specialist facility, under supervision, and with proper monitoring, and for there to be a provision in the law to allow for that.
Yeah, force people to write a big pile of nested bracket spaghetti...
1. "nested brackets" (blocks) are by definition not spaghetti. Spaghetti is exclusively the result of gotos and their control equivalents (like the early return).
2. Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
He's innocent until proven guilty, regardless of whether or not he resigned. And a little more circumspection would be nice.
I bet you wouldn't be nearly so circumspect had it been a Labour politician.
Quote right. It seems to be used mainly for tackling torrent sites. Protecting the media companies is far more important than protecting children.
No the issue was with conditionals and braces. The same issue would have happened even if it were two return statements .
And a return statement before the end of a function is essentially a goto. A language that takes the step to rule out gotos should also not allow early returns.
"given enough eyeballs, all bugs are shallow"
Apple had their goto bug in TLS for about 18 months before they spotted it.
GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.
Then lets not have it again.
OK, exchanges are more like bureaux de changes. And bureaux de changes are also subject to banking system regulation So it comes to the same: regulated vs unregulated.
Bitcoin is an open source concept and codebase.
I thought you were wanting to defend it?
Digression: Remember the Apple SSL security bug last week? How it was relished by open source types with talk of open source having "many eyes making all bugs shallow". Well it turns out that Linux and every other OS relying on GnuTLS has had a similar security bug since 2005.
http://arstechnica.com/securit...
Cryptocurrencies are here to stay as they are merely more efficient tools.
They are bound to fail, as they have no regulator, nor compensation scheme.
And then, how many people are keeping the bitcoins themselves without adequate off-site backup?
In the general population maybe 5% of people have off site backups. Do they suddenly become wiser when they have bitcoins? Maybe a bit. But I'll bet it's still far less than half that have a proper backup system.
It's not just trust. It's also regulation and associated official compensation schemes. That's what makes for a real banking system. And what is lacking in Bitcoin.
Occam's Razor says, even if there was no governmental or corporate involvement in the heist, they won't bend over backwards to help the victims recover their losses, and just may be quietly cheering on the 'thieves' from the sidelines.
You say it like it's a bad thing. One of the objectives of bitcoin users is to avoid paying tax. And yet you believe governments should "bend over backwards" to help cover the inevitable losses from an unregulated market? Covered presumably by the tax paid by people using ordinary currencies.
You can't have it all ways.
The one the governmental actors target? We know they want to discredit bitcoin.
And so the narrow line between libertarianism and paranoia is crossed.
Apple's site lists a number of third party apps with CarPlay functionality and promises more to come.
Ah, I missed those. But I'd guess it's specific partnerships, rather than an open App Store like arrangement.
And to the GP, mirroring is a terrible idea - not only because a car's built-in display will almost certainly have a different aspect ratio and resolution, but because an interface designed for use in a car is (should be) different in some ways to that of a phone (even more streamlined, simplified, and with larger fonts).
Yes, straight mirroring would be bad. But Airplay already allows iOS video out devices to be different resolutions and to display different contents from the built in screen. So presumably no problem there.