Thread: Proof that professional programmers can be braindead

Well, not necessarily professional programmers, but you can't argue that OpenSSL or procmail aren't or haven't been heavily used programs.

Whilst reading reddit, I stumbled upon this link: cortesi - Reading Code: In praise of superficial beauty

It discusses the importance of superficially beautiful code, and also shows several examples of major products whose code is so bad that it might, at least in the case of OpenSSL, make you worried about your privacy.

If you read further on that link, you might see this link:

procmail.c

It is, hands down, the ugliest piece of code I have ever seen. I actually tried tracing through the code, but I went nowhere.

However, the first place of ........ups still goes to OpenSLL, for the if statement with 0 as a condition, and a goto label inside it, to guard the code inside it from ever getting executed unless you jump into it.

I guess there is one thing that is certain, though. No sane man would be able to actually derive any information from the OpenSSL code that could potentially expose vulnerabilities. If they're there, you'll have to fuzz them out. Code analysis won't do you good. It might send you to a mental health institution.

The first time I heard of a "fencepost error" it involved a piece of historical SSL code that had been exploited and subsequently corrected.

Originally Posted by IceDane

However, the first place of ........ups still goes to OpenSLL, for the if statement with 0 as a condition, and a goto label inside it, to guard the code inside it from ever getting executed unless you jump into it.

What's wrong with it? It's a well known technique considering C has no exception handling. It's not just some cheap horror trick.

Sometimes you see things like this in C:

Code:

int func()
{
  ...
  if(ptr_a == NULL) goto oops; // oops, go to exception handler
  ...
  return 0; // normal return
oops:
  // this handles an 'exception'  
  ...
}

This is essentially a cheap form of exception handling. It's an easy way to keep the flow and logic behind what can go wrong clear to the programmer (goto's are probably most used for things of this nature today.)

There's a problem however, how do you do this in nested scope?

Code:

int func2()
{
  if(ptr_a == NULL) {
   /// ????
  }
  ...
}

The problem is that at the point of ?????, if an 'exception' happens, you need to continue by eventually moving out of the scope of the if and returning to the normal program flow. But you can't just put a return at ??? followed by a block with your 'exception handler': the only way to get out of scope is to fall off the end, so where can you put your exception handler, without executing it, while getting out of the scope?

You model try, catch and finally:

Code:

int func3()
{
  if(ptr_a != NULL) {
    ...
    // try
    if(ptr_b == NULL) goto oops;  

    if(0) {
      oops:
      // 'catch' block
    }
    // finally
    ...
  }

}

The if(0) perfectly solves this problem of dealing with this problem inside nested scope (or out of it, for that matter,) and it lets you continue the normal program flow after the 'exception handling' has happened. It may seem awkward, but it's a decent representation of exception handlers in C when you need it. You could use macros to make it look nicer if you want:

Code:

#define THROW(x) goto x
#define CATCH if(0)

int func4()
{
  if(a == 2) {

    if(screwed) THROW(got_screwed);
    ...
    CATCH { got_screwed:
      ...
    }
    ...
  }
  ..
}

Huh, I thought you're not allowed to jump into control blocks ...

Originally Posted by Mad_guy

This is essentially a cheap form of exception handling. It's an easy way to keep the flow and logic behind what can go wrong clear to the programmer (goto's are probably most used for things of this nature today.)

I think Linus himself does that too.