int result = ERROR_CODE;
    FILE * f = NULL;
    char * s = NULL;
    if((f = open_file()) == NULL) goto end;
    if((s = allocate_string() == NULL) goto closefile;
    if((some_other_thing() == NULL) goto freestring;
    ...
    result = NOERROR;
  freestring:
    free_string( s);
  closefile:
    close_file( f);
    return result;

And really, the extra condition check likely isn't going to affect the critical path, but it will make it a lot easier to reason about the code, especially when someone else has to modify it.

I say this from the point of view of someone having to debug your code: "OK so step, step, step, run to this line... wait, what? How did this function return when there is no return statement? Let me run that again from the beginning... ... ... What? This ASSERT macro doesn't actually assert it just returns?"

Keyboard out window etc.

Please stick to language conventions. Macros are bad because they hide what the code is actually doing.

http://www.cplusplus.com/reference/cassert/assert/

Quote from the link: Therefore, this macro is designed to capture programming errors, not user or run-time errors, since it is generally disabled after a program exits its debugging phase.

Of course you can name your macro whatever you want, even assert, but it will confuse other developers used to c library functions.

The benefits of the macro (IMO) aren't obvious from the example I gave. Like I said, I'm currently working on a personal project where macros have been the saving grace. Attaching a conditional return to every individual statement was making my code extremely hard to maintain (even for myself, who wrote it) -- wrapping common error cases in a macro made everything a whole lot simpler, and allowed me to work on my algorithms at a high level without having to run my eyes over the same error-checking `if` statements a million times.

> I don't understand why it says "do ... while (0)" in the macro, for instance.

It's normal for many macros, so that you can use them like normal statements.

> In your example, you're just going to leave the file open and the string allocated?

I sort of just made that example up off the top of my head -- you're right about the memory leak.

That's precisely what premature optimization is: Reducing assumed overhead before you've even established where the bottleneck is, if any. By using a macro, you've traded away all of the benefits of a function. If you had demonstrable need to avoid the function call overhead, you could have declared the function inline static.

Most performance issues can be solved with algorithmic changes. This level of optimization should only be done as a last resort, and profiled extensively to ensure that you really are making a difference for the better. Many "low level" tricks that on the surface look like they'd speed things up can in fact have the opposite effect on modern processors. For example, it's possible that this macro optimization could blow up your cache if some_operation gets called a lot and you tried unrolling loops.

Right-click -> Go to definition?

Your IDE must suck.

Apart from your already ( apparently )wast knowledge of various development tools, please also consider improving your conversational skills.

  if ((f = open_file()) == NULL)
  {
    RETURN_ERROR(OPEN_FILE_ERROR);
  }
  if ((s == allocate_string()) == NULL)
  {
    RETURN_ERROR(ALLOCATE_STRING_ERROR);
  }
  if ...

  #define RETURN_ERROR(my_error) { \
    if (f != NULL) { fclose(f); f = NULL; } \
    if (s != NULL) { free(s); s = NULL; } \
    ...
    return (my_error); \
  }

  if(failure_1) {
      goto error;
  }
  if(failure_2) {
      goto error;
  }
  
  // Do stuff
  return 0;
  
  error:
  if(f != NULL) {
      fclose(f);
  }
  if(s != NULL) {
      free(s);
  }
  return -1;