I don't think the comment 'we do not recommend general use of these functions' applies, becaue this is not one of those undocumented internal-use builtins.

Should this be best practice? In gcc project they say:

"GCC provides a large number of built-in functions other than the ones mentioned above. Some of these are for internal use in the processing of exceptions or variable-length argument lists and are not documented here because they may change from time to time; we do not recommend general use of these functions."

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

What the hell? How is that clever

Python 3.8 should be enabled.

Several issues:

1. return *lg = 0; -- return value is wrong.
2. char **ret = malloc(sz * sizeof(char**)); -- not correct. Correct is char **ret = malloc(sz * sizeof(char*));
3. If all strings in arr are freed after dirReduc call, the result will become invalid.

it's not fair

@B4B You still didn't mark it as spoiler! x/

Not an opinion. It's just a fact.

For me this is over.

It doesn't compile in another compilers. For example try to compile it into Visual Studio C++

Also, the implementation it's not yours. You're using a builtin function that only the GCC compiler has implemented. So, I must say that it's only a nice trick. But must not be considered best practice by no means.

It's faster than other implementations (including mine)? YES
Has been implemented by you? NO
Must be considered a solution to the exercise? NO!

1. SPOILER FLAG!! Damn you! x/
2. there is always an overhead about the docker/runner/.... Comparing the performances like you do right now is totally pointless and actually totally nuts. Moreover when there are random tests, and when the time you use includes the generation of the tests too.

It works, right?

It's the lower 8 bits of edi (like al to eax)

hmm... :/ I use MASM I keep having to look at NASM references. wonder if they will add MASM.
I will study this DIL.