Cool

ssruh?!

indeed it is a Bruh

I think using f-strings should be the best practice nowadays

yes, the uint32_t only allow integers without sign, this mean only can be positives

good luck passing your negative values when the params are unsigned ints.

would this still work if we give negative values to m and n?

You are perfectly correct, this is not standard and very bad practice. It would not compile on MSVC. I did not know about void * arithmetic at the time I solved this kata, I wish there was a way to warn users about it, like passing -Wpointer-arith to the compiler. You can program for months on GCC/clang and not realise this (and other things) are not standard.
Compiler extensions are evil sometimes :(

how??

Should be noted that pointer arithmetic on a void * is not standard C. void is a permanently incomplete type by definition, which means its size is always unknown.

void * arithmetic is primarly a GCC extension (wherein sizeof (void) is defined as 1) that a few other compilers have followed suit with for compatibility.

The maximum value representable by traditional Roman numerals is 3999. The longest possible string of characters is "MMMDCCCLXXXVIII", a value of 3888, with a length of 15. Therefore you need a maximum of 16 bytes to store the longest possible encoded string.

There's no way this code will overflow a 50 byte buffer - ironically the buffer is actually too large.
The most egregious things here are that the arguments to calloc are flipped, and that strcat has to reiterate.

Putting the string on the heap is important since we need writable memory. If you were to use so-called VLAs (e.g., a string allocated on the stack you could get non-writable memory). In C stack-allocated strings should be considered immutable.

?!

You can absolutely have mutable strings on the stack. char buf[11]; would work just fine for both your solutions.

Seems like you got pointers and arrays confused. A pointer to a string literal (stored in the data segment) is not a "stack-allocated string". There's a significant difference between const char *foo = "bar"; and char foo[] = "bar";.

VLAs don't particularly factor into this, but they are absolutely mutable (seeing as they cannot be initialized, they would be useless otherwise). There is no such thing as "could" when dealing with well defined behaviours.

error: storage size of ‘newArray’ isn’t constant

You cannot specify the storage size of a static object at runtime.

The test cases for this kata do not free the returned memory - the only sensible option is to mutate the input (array) and return it.

For anyone wondering: you are to find the next prime, which is not necessarily the closest prime.

e.g., starting from a sum of32 the next prime is 37, even though the closest prime is 31.

This is somewhat hinted at by "List's numbers will only positives (n > 0)" (should say n >= 0), such that the difference between your found prime and calculated sum (the number to be 'inserted') is strictly greater than or equal to zero.

This is additionally confusing, at least for C, since the solution uses a signed data type.