Ad
  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    C tests output several warnings; some critical. Types need matching, and strdup requires an appropriate macro (#define _GNU_SOURCE or equivalent).

    fixture.c:41:31: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
        for (int trial = 0; trial < count; trial++)
                            ~~~~~ ^ ~~~~~
    fixture.c:44:19: warning: comparison of integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
                k   = min(rand() % (maxK + 1), len+1);
                      ^   ~~~~~~~~~~~~~~~~~~~  ~~~~~
    fixture.c:5:22: note: expanded from macro 'min'
    #define min(a,b) (a) < (b) ? (a) : (b)
                      ~  ^  ~
    fixture.c:70:15: warning: implicit declaration of function 'strdup' is invalid in C99 [-Wimplicit-function-declaration]
        char *t = strdup(s), *r = malloc(len + 1);
                  ^
    fixture.c:70:11: warning: incompatible integer to pointer conversion initializing 'char *' with an expression of type 'int' [-Wint-conversion]
        char *t = strdup(s), *r = malloc(len + 1);
              ^   ~~~~~~~~~
    4 warnings generated.
    
  • Custom User Avatar

    The obvious method in JavaScript is very naive. Mathias Bynens explains very well in this answer on Stack Overflow. See the related library, Esrever.