Goto fail;

dkf

Are you high? There are no explicit variables in the code at all.

A realistic implementation might pass in the values it needs to in variables!!! (A realistic compiler might inline things; separating things can just make it easier to comprehend what the code is doing, which is definitely important too.)

anotherusername

@Faxmachinen said:

@orokanasaru said:
Wow, that is a great solution... Why confine variables to local scope when you can just make everything a global?

Are you high? There are no explicit variables in the code at all.

I think that orokanasaru was referring to these:

SUCCESS

INIT_SUCCESS

INIT_ALLOC_FAILED

INIT_INTERRUPTS_FAILED

INIT_REGISTERS_FAILED

Hurray for magic numbers - after we name them, we have to keep them. Right?

orokanasaru

@Faxmachinen said:

Are you high? There are no explicit variables in the code at all.

Now I'm just curious as to how you are expecting free_memory() to free the memory allocated by allocate_memory() without some sort of non-local state

dkf

@orokanasaru said:

Now I'm just curious as to how you are expecting free_memory() to free the memory allocated by allocate_memory() without some sort of non-local state

It's amazing what you can do with scoped thread-locals. Though there's still technically non-local state, the evilness is tamed.

Faxmachinen

@orokanasaru said:

Now I'm just curious as to how you are expecting free_memory() to free the memory allocated by allocate_memory() without some sort of non-local state

Oh I'm sorry, I didn't realize you wanted me to rewrite the entire API for some fictional module rather than provide an example on how to avoid goto. My bad.

PJH

@orokanasaru said:

Now I'm just curious as to how you are expecting free_memory() to free the memory allocated by allocate_memory() without some sort of non-local state

The memory allocated may carry some of that information with it. OK, it's not 'local' but it certainly isn't globally accessible in the normal sense of the concept.