Ad
  • Custom User Avatar

    I recommend that you put your kata into Draft mode whilst adding random tests.

  • Custom User Avatar

    I'll take a look soon, on mobile right now and it's too cumbersome...

  • Custom User Avatar
  • Custom User Avatar
    • tester() could be significantly streamlined:
      • use your dedicated stringer() function to stringify the input, expected and actual arrays
      • the comparison of integer arrays can be done in one line:
      bool equal = (exp_len == sub_len) && !memcmp(submitted, expected, exp_len * sizeof *expected);
      
    * You chose to pass the result as an output parameter. This is fine, but as usual in C, when you provide a buffer to the user, you must document how large they can expect the buffer to be. This is a crucial information that is part of the function's contract, as it allows or disallows some ways of writing the solution (For example, some users will first copy the entire input to the output, and only then filter out the rejected elements from the output). You have 3 choices:
     * change the interface to return a heap-allocated array, letting the users deal with the memory allocation themselves
     * keep the interface as is, but clearly document in the initial code what can be assumed about the length of the output array
     * Since the length of the output is always at most that of the input, change the interface to pass an input/output array that must be mutated in-place
    
     I would prefer option 3, as it makes the solution a bit trickier to write, but you can choose whichever you want. Also note that in the last 2 options, the output length could be returned directly by the function, instead of having a `void` function and an extra parameter.
    * what is the `crash_prevention` thing ?
    
  • Custom User Avatar

    Here is the official documentation on Random Tests.

  • Custom User Avatar
  • Custom User Avatar

    everywhere you write bool (*predicate)(int), you can write Predicate predicate instead

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar
    • added int
    • used typedef
    • made description anonymous
  • Custom User Avatar
    bool (*predicate)()
    

    Empty parameter lists (()) before C23 mean "takes an unspecified number of parameters of unspecified types" (in C23 it means the same as (void)). Their behavior should not be relied upon, as it is a legacy feature that forgoes type safety (For example reject() will hapily accept a call with a function such as

    bool foo(char *x) { return *x == '0'; }
    

    and crash when it passes an integer to foo()).

    You have to add int to the parameter list. Also, function pointers are usually handled through a typedef:

    typedef bool (*Predicate) (int);
    
  • Custom User Avatar

    approved

  • Custom User Avatar

    fixes merge conflict

  • Custom User Avatar
  • Custom User Avatar

    On the other hand, if in fact you're asking why the kata has the particular rules that it has, that would be a question for its author. Beyond that, we remain tasked with following those rules to come up with a solution, regardless of to what degree it could be assessed as a reasonable real-world situation.

  • Custom User Avatar

    So, Why don't we reduce both cases?

    Because of the logic of the kata.

    I know what is the logic of this kata.

    So use that to solve the kata.

  • Loading more items...