why do we need list comprehension [] here?

Initializing a hash array and temp string with calloc is lame. Better initalization would be: int arr[256] = {[0 ... 255] = 0}; char numstring[5] = {[0 ... 4] = '\0'};

Also, you forgot to free numstring! So how is this BestPractices???

calloc allocated blocks come earased

I think this is a great Kata. It's dealing with a baffeling and somewhat mysterious sequence. There is for sure a recursive solution to calculate the numbers. But it should be considered, that recursive solutions could be waaayyy too slow calculating higher numbers...

This is kind of verbose!
What regex is made for: to shorten such code.

Yeah, me too, I definitely join the downvoters.
But it's something like a valid solution.

Oh, my, as I expectd, my brute force approach for JavaScript passed the first tests but timed out on the 'attempt'-tests. So I have to try something different... Maybe with a generator-function.

it's not about allocation, it's about casting. strlen() returns a size_t value, comperable to unsigned long. so, just change the type of i in your for loop and that should do it

OK, solved!

In my C solution the test always says:
Test Crashed Caught unexpected signal: 6
Completed in 0.0000ms
STDERR
setup.c:46:21: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
for (int i = 0; i < strlen(str); i++) {
~ ^ ~~~~~~~~~~~
1 warning generated.
munmap_chunk(): invalid pointer

On my computer it runs perfectly, also with valgrind, I cannot find a memory leak.
I checked the mallocs, but everything seems to be fine. Maybe I should increase/decrease the size of the allocated memory?

Language: Python
Skill level: Absolute beginner

Thought I'd come up with a pretty good (by my standards) solution to this one, but when I run it, it times out. No problem, inefficient code is my bet.
However, by purposely causing it to fail (simply leaving out the final integer to the array/list each time) it's essentially "passing" (or, would be) fairly consistently at around 2000ms, +/- 200ms.

Now I don't know the specifics of how execution time works, but it doesn't seem right to me that this last digit in each array can be slowing the whole thing down by five times or more... Can it?
Leaving out the final two integers instead of just the one doesn't seem to make it run any faster (on average, due to random tests), and some of these arrays have thousands of integers in them, so that kinda rules out some kind of exponential error/loop, right?

I know it's something wildly obvious that I'm missing, but if anybody has the time to explain what I'm doing wrong I'd really appreciate it. I'll post some lightly commentated code below if anybody is interested in helping.

For the C solution I'd definitely rank it as 6 kyu.