You do not free sdup, therefore leak memory.

res is overwritten by asprintf, so we need to save previous value of res to free memory.

You never free str, therefore, leak memory.

In case of sz <= 0 || l == 0 || sz > l you return static string which cannot be freed. In other cases you return allocated string. This requires from caller additional checks whether to free the returned string or not, so it is not very convenient.

In case of strlen(s) < sz || sz <= 0 you return static string which cannot be freed. In other cases you return allocated string. This requires from caller additional checks whether to free the returned string or not, so it is not very convenient.

Initial value of *lg == -1 is not documented.

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.

When you call pop, you should free the string you pop. Otherwise you get memory leak.

What if someone free strings in the input array right after dirReduc call? The result will become invalid and if you will try to read the result, you will get undefined behavior. This cannot be "Best Practice" solution.

Why do we need strdup here?

if after realloc newRes is NULL, you will have:

1. memory leak because you do not free allocated pairs
2. either undefined behavior (if Pair* solution = (Pair*) malloc(sizeof(Pair)); fails) or wrong solution because after res = NULL; you do not return or break

It is not correct to compare floating point numbers for equality because of limited precision. More on the topic:
https://www.jetbrains.com/help/resharper/CompareOfFloatsByEqualityOperator.html
https://stackoverflow.com/questions/328475/should-we-compare-floating-point-numbers-for-equality-against-a-relative-error

Also floating point operations are slow. So it is better to check for division remainder via a % b != 0 instead of ceil(a / b) != a / b.

// number of factors is not less than bits number -- not correct. Correct: // number of factors is not greater than bits number

I know only one case when goto is useful in C: for cleanup (https://stackoverflow.com/a/245761). For all other cases Dijkstra's paper applies:

I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code).

The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress.

When one uses goto, it becomes hard to see the control flow just by looking at code.