Enforce C formatting in Soter and Themis tests

[ilammy]

Reformat the tests in accordance with the code style.

The code looks unreadable in some places, but meh... We use way too many long_and_detailed_multi_word_identifiers as well as test macros which effectively require to write code in a single line.

I'd suggest us to just deal with it (⌐■ _■) Let's leave this code as is now. For new code we can make an effort to keep it readable with the new formatting rules. Older code can be refactored to be more readable when we actually change it.

[vixentael]

Uh oh, it's really complicated to read

    testsuite_fail_unless(SOTER_INVALID_PARAMETER ==
                              soter_asym_cipher_init(&ctx, key_data, key_data_length,
                                                     (soter_asym_cipher_padding_t)0xffffffff),
                          "soter_asym_cipher_init: invalid algorithm type");

[vixentael]

changes-changes everywhere 🤔

[vixentael]

1. is it only for tests? shall we name it FMT_TESTS_SETUP?
2. is it ok to have these in main makefiles, maybe move to tests/test.mk?

[ilammy]

@vixentael,

1. is it only for tests? shall we name it FMT_TESTS_SETUP?

FMT_FIXUP is the variable which gathers all files to be formatted. We can introduce an intermediate variable to keep THEMIS_TEST_FMT_FIXUP and SOTER_TEST_FMT_FIXUP but it won't increase readability so I think it's redundant.

2. is it ok to have these in main makefiles, maybe move to tests/test.mk?

I have placed these lines in the main makefile because that's where compilation rules for test binaries are located. However, it really makes sense to put them into tests/test.mk. How about moving both new formatting rules and existing build rules for tests there?

[ilammy]

@vixentael I've moved the formatting setup as well as compilation to tests/test.mk.

[vixentael]

thanks! my inner perfectionist feels much better now. Also naming FMT_FIXUP has more sense now when places into tests.mk

[ilammy]

@vixentael

Uh oh, it's really complicated to read

This should be easier to understand but it requires a bit more changes and cannot be automated:

    result = soter_asym_cipher_init(&ctx, key_data, key_data_length, PADDING);
    testsuite_fail_unless(result == SOTER_INVALID_PARAMETER,
                          "soter_asym_cipher_init: invalid algorithm type");

[vixentael]

it requires a bit more changes and cannot be automated

ok-ok, i'm just complaining

[vixentael]

lgtm
(but complicated to read :D)

[ilammy]

it requires a bit more changes and cannot be automated

ok-ok, i'm just complaining

I'm very much triggered by the readability as well so I guess I'll be slowly fixing it up function by function when I need to actually change the files. It's not like I experience a physical pain in the eyes by looking at it, but the moral suffering from not being able to configure the formatter for beau-ti-ful code and having to look at this instead is still there.

Or maybe some day I'll discover that magical set of clang-format keys which makes the code readable out of the box (and we'll see yet another formatting-only commits).

[ilammy]

The checks did not pass because of a failure in Rust tests (again), but I've merged this PR regardless. I've seen this failure before and have a hunch about why it happens. Though, no solution yet.