I never understood this argument. Without RAII you can easily get screwed by res...

shakna · 2025-04-06T08:43:26 1743929006

Attributes, mostly. Which have become so common that defer is very likely to be in the next C standard. [0]

    bool function_with_cleanup(void) {
        // Allocate first resource
        int* buffer1 __attribute__((__cleanup__(free))) =  malloc(sizeof(int) * 100);
        if(!buffer1) { return false; }

        // Allocate second resource
        int* buffer2 __attribute__((__cleanup__(free))) = malloc(sizeof(int) * 200);
        if(!buffer2) { return false; }

        // Open a file
        FILE* file __attribute__((__cleanup__(fclose))) = fopen("data.txt", "r");
        if (!file) { return false; }

        return true;
    }

[0] https://thephd.dev/c2y-the-defer-technical-specification-its...

mkl · 2025-04-06T09:38:49 1743932329

Nested ifs are my preference:

  bool function_with_cleanup(void) {
      int *buffer1 = NULL;
      int *buffer2 = NULL;
      FILE *file = NULL;
      bool success = false;
  
      // Allocate first resource
      buffer1 = malloc(sizeof(int) * 100);
      if (buffer1) {
          // Allocate second resource
          buffer2 = malloc(sizeof(int) * 200);
          if (buffer2) {
              // Open a file
              file = fopen("data.txt", "r");
              if (file) {
                  // Do work with all resources...
                  fclose(file);
                  success = true;  // Only set to true if everything succeeded
              }
              free(buffer2);
          }
          free(buffer1);
      }
  
      return success;
  }

Much shorter and more straightforward.

One-time loops with break also work if you're not doing the resource allocation in another loop:

  bool function_with_cleanup(void) {
      int *buffer1 = NULL;
      int *buffer2 = NULL;
      FILE *file = NULL;
      bool success = false;
  
      do { // One-time loop to break out of on error
          // Allocate first resource
          buffer1 = malloc(sizeof(int) * 100);
          if (!buffer1) {
              break;  // Error, jump to cleanup
          }
  
          // Allocate second resource
          buffer2 = malloc(sizeof(int) * 200);
          if (!buffer2) {
              break;  // Error, jump to cleanup
          }
  
          // Open a file
          file = fopen("data.txt", "r");
          if (!file) {
              break;  // Error, jump to cleanup
          }
  
          // Do work with all resources...
  
          success = true;  // Only set to true if everything succeeded
      } while(false);
  
      // Free resources in reverse order of acquisition
      if (file) fclose(file);
      free(buffer2);  // free() is safe on NULL pointers
      free(buffer1);
  
      return success;
  }

Still simpler to follow than goto IMHO. Both these patterns work in other languages without goto too, e.g. Python.

gpderetta · 2025-04-06T14:07:31 1743948451

Nested if, aside from being awful, doesn't scale.

And break is extremely thin sugar on top of go-to.

dwattttt · 2025-04-06T02:56:40 1743908200

Open a scope when you check resource acquisition passed, rather than the opposite (jump to the end of the function if it failed).

It can get quite hilly, which doesn't look great. It does have the advantage that each resource is explicitly only valid in a visible scope, and there's a marker at the end to denote the valid region of the resource is ending.

EDIT: you mentioned early return, this style forbids early return (at least, any early return after the first resource acquisition)

gigatexal · 2025-04-06T05:56:21 1743918981

In this example couldn’t the go to cleanup instead be return cleanup_func where the same cleanup code was executed?

pjmlp · 2025-04-06T08:28:18 1743928098

Maybe that is exactly the problem, stop using a language designed in 1970's that ignored on purpose the ecosystem outside Bell Labs, unless where it is unavoidable.

And in such case, the C compiler doesn't have a limit to write functions and better modularize their implementations.

    bool function_with_cleanup(void) {
        int *buffer1 = NULL;
        int *buffer2 = NULL;
        FILE *file = NULL;        
        // Allocate first resource
        buffer1 = malloc(sizeof(int) * 100);
        if (!buffer1) {
            return false;
        }
        
        // Allocate second resource
        buffer2 = malloc(sizeof(int) * 200);
        if (!buffer2) {
            free(buffer1);
            return false;
        }
        
        // Open a file
        file = fopen("data.txt", "r");
        if (!file) {
            free(buffer1);
            free(buffer1);
            return false;
        }
        
        // Do work with all resources...
        fclose(file);
        free(buffer1);
        free(buffer1);

        return true;
    }

Ah, but all those free() calls get tedious can be forgotten and mistyped

    bool function_with_cleanup(void) {
        int *buffer1 = NULL;
        int *buffer2 = NULL;
        FILE *file = NULL;        
        // Allocate first resource
        buffer1 = arena_alloc(&current_arena, sizeof(int) * 100);
        if (!buffer1) {
            return false;
        }
        
        // Allocate second resource
        buffer2 = arena_alloc(&current_arena, sizeof(int) * 200);
        if (!buffer2) {
            arena_reset(&current_arena); 
            return false;
        }
        
        // Open a file
        file = fopen("data.txt", "r");
        if (!file) {
            arena_reset(&current_arena);
            return false;
        }
        
        // Do work with all resources...
        fclose(file);
        arena_reset(&current_arena);
        return true;
     }

Can still be improved with a mix of macros and varargs functions.

Or if using language extensions is a thing, the various ways to do defer in C.

LtWorf · 2025-04-06T08:57:36 1743929856

You understand go doesn't have exceptions right?

pjmlp · 2025-04-06T09:42:54 1743932574

You understand that I wrote C code, and in what concerns Go, panic/recover are exceptions that don't want to assume themselves as such?

LtWorf · 2025-04-06T20:36:32 1743971792

You can't handle a panic, it's the whole point.

9rx · 2025-04-07T16:34:38 1744043678

In C, you mean?

You clearly can in Go. How would you deal with exceptions otherwise? You can even get silly with it:

    func main() {
        try(func() {
            throw("Oops")
        }).catch(func(e any) {
            fmt.Println("Caught:", e)
        })
    }

https://go.dev/play/p/Y1-w9xUXIcO