using map here is actually really smart

is it not better to use a static map, to prevent multiplw initiations?

Integer object will have possibility of null value

It's because I am using global variables and calling function multiple times! Figured it out!

got it! Seriously thanks for your immense help! I have a hard time imagining
how I would have seen that without your help!

You say you think it contains some specific information. Do you have any promise anywhere that tells you this is so? Or any indication at all? If you look at the example code you can see how it is used. It does not put this length information there, or any other information, but the parameter is used, what's done with it?

Not required to answer that, but so that you have the full code - this is the preloaded function:
(and if anyone's feeling trigger happy on the spoiler button - don't. there is nothing secret in this.)

char* array2StringData(Pair** arr, int sz) {
    if (sz == 0) {free(arr); return "{}";}
    // for each pair length of 2 int + { + } +", " + 1
    int lgs = 0;
    for(int i = 0; i < sz; i++) {
        lgs += 10 + 10 + 5;
    }
    char *dest = (char*)calloc(1, sizeof(char) * lgs + 1);
    char *p = dest;
    *p++ = '{';
    for(int i = 0; i < sz; i++) {
        sprintf(p += strlen(p), "{%lld, %lld}", arr[i]->first, arr[i]->snd);
        //free the pair
        free(arr[i]); arr[i] = NULL;
    }
    // free array of pairs
    free(arr);
    int l = strlen(dest);
    dest[l] = '}'; dest[l + 1] = '\0';
    return dest;
}

As far as I can tell its the amount of pairs in the answer which is why I allocate the Pair** with that amount so the array of structs is that length.

Reconsider what the length param is for. What promises are you given about it, how is it used in the test code?

find a faster way to find divisors (maybe googling turns something up)

you can also try finding divisors for some numbers manually, humans are optimizing problem solvers so you might .. optimize it and then do the same thing in your code

With preloaded hidden or visible, it does not matter. Allocation scheme required for this kata is terrible, counterintuitive, and against every existing C rule.
Bonus points for designig a stringification function in a way it invalidates the stringified array. Yay.

I solved it just now as a C novice. I blame preload above all else - making it difficult to reproduce locally.
It wasn't enough to copy the test cases, I needed to reproduce the free's as well... Part of the API was hidden.

For C, the result is expected to be a dynamically allocated array of pointers to dynamically allocated individual pairs, which is beyond ridiculous.

I hope one day some update to C runner would render all C kata invalid, and force C authors to fix every translation they created in such a twisted, FUBAR shape like this one.

Now the question would be, will author fix the kata, or they will leave it broken "because solutions".

Call it and find out? But I imagine that since you're providing a location to read from, it would read from that location regardless of where it is. It wouldn't matter, would it?

I do wonder why you're talking specifically about dynamic/static allocation. Is this something you tested where you found one to work and the other not? Because if not then you have no indication that this is what it's about.

Getting a result of {} would mean that the array was never looked at at all, wouldn't it? The array itself would have no effect on this. What has an effect on this?