Better yet, just never do alignment.

Obviously readability is subjective, but personally I find alignment is never valuable outside of tables of data, and I'd argue generally having tables of data embedded in your code isn't ideal.

    #include<stdio.h>

    int main(int argc, char* argv[]) {
        printf(
            "%s %s %s %s\n",
            __FILE__,
            __LINE__,
            __DATE__,
            __TIME__
        );

        return 0;
    }

Reads better to me and avoids the issue entirely. It also plays more nicely with traditional diff tools anyway.

Yes, that was more or less the argument I was trying to do by the end of my comment: diffing is meant to be space agnostic (the -B option of diff(3)), but since code is committed with formatting, formatting will interfere.

That is the kind of problem solution that ends up with you now having 2 problems. New problem(s); having tabs and spaces, having to think when to use them, having to train/document everyone in usage, having to debate that usage, having to correct code and chastise people who get usage wrong.

Use a automatic code formatter with minimal options. Automate either running code formatter on commit or denying commits that change when code formatter is run on them.

Absolutely, I wouldn't dream of doing any kind of fancy alignment by hand, only with an auto-formatter.

If I had to break arguments onto multiple lines without an auto-formatter I would just keep it simple and use another level of indentation instead of aligning them with the function name.

Interesting idea.

This will work with C (for now), but it will fail with language like C++ where you can have lambdas. When a lambda is a function parameter, it will need to be aligned to other parameters, but the lambda body will require indentation.

Of course, there are ways of avoiding the problem, eg. by using a variable for the lambda, yet isn't this sweeping things under the rug?