Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goto (2007)

beej.us

Post reply on HN
Print view View original

81–90 of 207 posts

Re: Goto (2007)

#81

Post by lmilcin »

JKCalhoun wrote: post #78

> Multi-level Cleanup Used all the time a decade or so ago when writing code that made heavy use of Apple's CoreFoundation. CF could return nil (failure) for many operations, and memory management at that time was left up to the programmer. // Not real code, approximated from recollection bool createNestedCFThing () { CFDictionary *thing = nil; CFArray *arrayObj = nil; CFString *string1 = nil; CFString *string0 = nil…

This is my favorite use of goto. Not only it makes it more readable and easy to ensure the cleanup is only executed, it results in efficient binary representation which is important for some of the embedded stuff I am doing.

Re: Goto (2007)

#82

Post by lmilcin »

throw_m239339 wrote: post #40
enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

> Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"? There is no need to use GOTO when a language has functions/procedures and exceptions. Of course it makes sense in Assembly…

> There is no need to use GOTO when a language has functions/procedures and exceptions.

There is no need for exceptions either. Everything can be done with error code.

Just because there are redundant mechanisms to achieve same result does not mean one of them must be abolished.

Re: Goto (2007)

#83

Post by lelanthran »

metarox wrote: post #76
lelanthran wrote: post #24

Earlier quoted context omitted.

> For instance, MISRA C rule 15.1 that states that goto should not be used explains: "Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand" Sure, but constrained uses are fine, right? So why blanket-ban it?

MISRA doesn't ban it, that rule is only Advisory which pretty much means you can ignore it. Rules 15.2 and 15.3 (Required) define how you can use goto if you decide to use it. Rule 15.2 The goto statement shall jump to a label declared later in the same function (forward gotos only) Rule 15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement (ca…

I'm familiar with MISRA (embedded dev), I only wanted to point out that the MISRA rules in no way justifies a blanket ban on gotos.

The ban (in the case of C, anyway) is almost always the result of someone's completely subjective opinion that gotos are bad.

Re: Goto (2007)

#84

Post by hyperman1 »

SAI_Peregrinus wrote: post #59
hyperman1 wrote: post #20

There are a few situations like this, where a bad practice is in a specific case good enough: Using goto to bail out multiple levels, using SHA-1 as a non-secure hash, ... The problem is these things waste social bandwith: Someone reading your code for maintenance or code review will first declare the code bad (GOTO is ugly! SHA-1 is insecure!), then you have to signal to them that it's actually OK in this case, then…

> using SHA-1 as a non-secure hash, That I actually partly disagree with. There are much, MUCH better performing (faster, less memory use, etc) hashes than SHA1 if you don't need security. If you don't need security, and you don't need performance, and you don't have anything else available in libraries, then SHA1 is fine. But that's a pretty rare situation. SHA1 might not be a sign of insecurity, but it's often a si…

I'm not going to contradict you. This was just one random example, based on the git/SHA-1 story. To stay in this example: If someone is claiming SHA-1 is faster for them, I'd expect to document what other algorithms they tested, what the numbers were, why better things were unavailable. A future maintainer can check if the decision still makes sense based on the comment. Hence the huge comment from the post above.

The problem is, I have a few examples that make a lot more sense, but they can't be published here. They depend on local corporate circumstances and pretty obscure knowledge, and would be undecipherable for the HN crowd.

Re: Goto (2007)

#85

Post by metarox »

lelanthran wrote: post #83
metarox wrote: post #76

Earlier quoted context omitted.

MISRA doesn't ban it, that rule is only Advisory which pretty much means you can ignore it. Rules 15.2 and 15.3 (Required) define how you can use goto if you decide to use it. Rule 15.2 The goto statement shall jump to a label declared later in the same function (forward gotos only) Rule 15.3 Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement (ca…

I'm familiar with MISRA (embedded dev), I only wanted to point out that the MISRA rules in no way justifies a blanket ban on gotos. The ban (in the case of C, anyway) is almost always the result of someone's completely subjective opinion that gotos are bad.

I fully concur on that last statement!

Re: Goto (2007)

#86

Post by adrian_b »

SAI_Peregrinus wrote: post #59
hyperman1 wrote: post #20

There are a few situations like this, where a bad practice is in a specific case good enough: Using goto to bail out multiple levels, using SHA-1 as a non-secure hash, ... The problem is these things waste social bandwith: Someone reading your code for maintenance or code review will first declare the code bad (GOTO is ugly! SHA-1 is insecure!), then you have to signal to them that it's actually OK in this case, then…

> using SHA-1 as a non-secure hash, That I actually partly disagree with. There are much, MUCH better performing (faster, less memory use, etc) hashes than SHA1 if you don't need security. If you don't need security, and you don't need performance, and you don't have anything else available in libraries, then SHA1 is fine. But that's a pretty rare situation. SHA1 might not be a sign of insecurity, but it's often a si…

On modern Intel/AMD and ARM CPUs, which have SHA-1 instructions, SHA-1 is very fast, faster than many apparently simpler hashes.

There are no other so fast hashes with an output of at least 128 bits that you can find in available libraries and use immediately in your code.

The only alternative that is faster and long enough is to use an 128-bit polynomial hash like Poly1305 or the one used inside AES-GCM. Such polynomial hashes are available in various cryptographic libraries, but they are not packaged in a way that would allow them to be used directly in a hashing application, so you might have to extract the code from the library and add an interface to it, to make it usable.

Another alternative that has appeared recently is BLAKE3. BLAKE3 can be much faster than SHA-1, but only when it is computed in parallel with a large number of cores. If you do not want your hashing task to entirely take over your computer, SHA-1 remains faster.

There are many applications that need long hashes to make negligible the likelihood of a collision, e.g. for file deduplication. For such applications using SHA-1 is by far the least effort choice and there is no disadvantage in using it.

Re: Goto (2007)

#87

Post by jcranmer »

enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

What is done is that people have taken the useful cases of goto, categorized them, and use renamed keywords for different cases. In many modern language, there are four keywords that all imply a general feature of goto: break (go to the end of the identified block), continue (go to the increment block of the identified loop), early return (go to the function cleanup code), and throw (go to something complicated). Indeed, with labeled break and labeled continue, you can actually produce almost any arbitrary control flow [1].

The last major use of goto in C is to recreate what many languages solve via some form of destructor, defer statement, with statement, or some other mechanism that has the compiler insert specified cleanup code on all exiting paths from a block. If you use such a mechanism, then it becomes impossible for the programmer to accidentally skip over such cleanup code, whereas a C function using goto might have the programmer write an early return instead of the goto by accident and skip it. And this is why there's a strong anti-goto sentiment: we have better tools [2] to achieve the same ends that are less error prone than goto is. And when you have the better tools available, why shouldn't you ban the worse tools?

[1] The one thing you can do with goto that you can't do with labeled break/continue is create irreducible control flow graphs (essentially, a loop with two entry points, thus having no dominator within the loop itself). On the other hand, I'm pretty sure that murdering a programmer who creates an irreducible control flow graph is considered justifiable homicide, so no harm is lost by outlawing it.

[2] In languages other than C, though.

Re: Goto (2007)

#88

Post by mkipper »

JKCalhoun wrote: post #78

> Multi-level Cleanup Used all the time a decade or so ago when writing code that made heavy use of Apple's CoreFoundation. CF could return nil (failure) for many operations, and memory management at that time was left up to the programmer. // Not real code, approximated from recollection bool createNestedCFThing () { CFDictionary *thing = nil; CFArray *arrayObj = nil; CFString *string1 = nil; CFString *string0 = nil…

This is the most common form of error handling used in the Linux kernel (at least the parts I look at). Although you'd normally have one error label for each allocation in reverse order, so you can jump to the cleanup step for the most recently allocated resource and pass through the other labels and clean them up as well. So in your example, it would be something like:

  bail_string1:
    CFRelease(string1);
  bail_string0:
    CFRelease(string0);
  bail_array:
    CFRelease(arrayObj);  
  no_bail:
    return thing;

Re: Goto (2007)

#89

Post by t43562 »

I find that using goto for cleanups makes many functions much much clearer and I think it cuts bugs.

Rather than writing the cleanup that is appropriate for each particular exit point you write one big cleanup at the end of the function that deals with everything.

It adds some potentially unnecessary if statements (to see if some pointer was allocated or not before trying to free it or to see if some file handle was opened before closing it). To me it has always seemed well worth it - shortening the code and greatly simplifying the chains of error-handling if statements.

Re: Goto (2007)

#90

Post by efaref »

IshKebab wrote: post #52
enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

It's not at all like that. `goto` leads to hard to follow, bug-prone code. > Why would an otherwise sane person write code with "rep" and without ever using "jmp"? They wouldn't. Nobody is suggesting that you should avoid `jmp` in assembly. I think maybe you missed the point? The whole "avoid goto" thing is talking about higher level languages than assembly that provide proper flow control primitives like `if`, `for`…

Avoiding jmp in assembly is a sensible thing to do. jmp may stall the pipeline if the branch predictor is wrong. Better to use cmov when you can.

And if we're being silly, you only really need mov[1].

[1]: https://github.com/xoreaxeaxeax/movfuscator

Post reply on HN