If a section of code isn't readable when using early returns, the correct way to handle it is usually to rethink how you're using that function. You're correct that sandwiching if statements with early returns in between pieces of logic is a bad idea, but that likely means you need to refactor the function, either by rearranging the blocks or breaking out the different pieces into other functions.

Here's a very slightly modified version of your code with early returns:

int load_file_into_buffer(const char *path, struct buffer *buffer)
{
    // declare variables at the top to prevent having declarations all over the place
    handle_t file = open_file(path);
    ulong file_size;

    //error handling
    if(file == INVALID_HANDLE)
    {
        report_failure("Failed to open file.");
        return -1;
    }
    if(get_size_of_file(&file_size, file) < 0)
    {
        report_failure("Failed to get file size");
        close_file(file);
        return -1;
    }
    if(!file_size)
    {
        report_failure("File is empty.");
        close_file(file);
        return -1;
    }

    // logic
    buffer->size = file_size;
    buffer->data = allocate_memory(buffer->size);
    if(read_from_file(buffer->data, buffer->size, file) < 0)
    {
        report_failure("Failed to read file.");
        close_file(file);
        return -1
    }

    close_file(file);
    return 0;
}`

Notice how all of the early error-checking if statements all happen in a row where it's easy to see that that's what that section of code does. The rest of the logic (including another if statement) is similarly grouped.

You can increase readability even more by noticing that this function has two responsibilities (opening and checking a file from a path as well as loading it into a buffer). Breaking these responsibilities into their own functions makes the code even more readable:

handle_t *load_file_from_path(const char *path)
{
    handle_t file = open_file(path);
    ulong file_size;

    if(file == INVALID_HANDLE)
    {
        report_failure("Failed to open file.");
        return -1;
    }
    if(get_size_of_file(&file_size, file) < 0)
    {
        report_failure("Failed to get file size");
        close_file(file);
        return -1;
    }
    if(!file_size)
    {
        report_failure("File is empty.");
        close_file(file);
        return -1;
    }

    return &file;
}

int load_file_into_buffer(const handle_t *file, ulong file_size, struct buffer *buffer)
{
    buffer->size = file_size;
    buffer->data = allocate_memory(buffer->size);
    if(read_from_file(buffer->data, buffer->size, file) < 0)
    {
        report_failure("Failed to read file.");
        close_file(file);
        return -1
    }

    close_file(file);
    return 0;
}`

Now it's even more clear what your code does.

Importantly, this sort of refactor was only as easy as it was because of the early return breaks. In this example it would be pretty easy either way, but in larger, more complex functions where the extended nested if statements have logic sparsely littered throughout, refactoring or reformatting your code is much more difficult. And adding/extending functionality is even more difficult.

If your nesting if statements are only one or two deep and the logic behind them are easy to understand, then by all means, nested ifs are fine. But in the vast majority of cases (especially cases like your example), using early returns are much easier to write, read, and reason about than nested ifs.