I don't know about your solution, but with C this is not uncommon to happen. This sometimes happens due to undefined behavior (UB) coming from your solution and influencing the tests. I was told that it's difficult / impossible to combat this from tests' side.

I only wrote code for returning words count, the array function words_to_array is empty.Solution got aproved. It does not check the array?

but you should specify what the problem actually is, because I'm not seeing it ( granted, I don't know much C ).

should mark this as an issue

You have to check if the element is greater then ALL to the right. Not just the next one over. So in your example you can see that none of them is greater then 105. The other one 14 isn't greater then 14 is why there is only one 14.

Approved.

Approved.

NASM fork with more informative tests logs.

Is there some question I cannot see?

NASM

Time: 646ms Passed: 4Failed: 3Exit Code: 1
Test Results:
negative_one_test
should_return_negative_value
The expression (make_negative(-1)) == (-1) is false.
Completed in 0.9982ms
Completed in 0.9982ms
negative_test
should_return_negative_value
The expression (make_negative(-9)) == (-9) is false.
Completed in 0.6710ms
Completed in 0.6710ms
one_test
should_return_negative_value
Completed in 0.3418ms
positive_test
should_return_negative_value
Completed in 0.5889ms
random_negative_test
should_return_negative_values
The expression (actual) == (expected) is false.
Completed in 1.0609ms
Completed in 1.0609ms
random_positive_test
should_return_negative_values
Completed in 0.8125ms
zero_test
should_return_zero_value
Completed in 0.6491ms

Description:

solve([1,21,4,7,5]) = [21,7,5]
solve([5,4,3,2,1]) = [5,4,3,2,1] ; first two elemnts: 5 is greater than 4 so is 5.

sample tests:

Assert::That(solve(V{16,17,14,3,14,5,2}), Equals(V{17,14,5,2})); why not {17,14,14,5,2}

Assert::That(solve(V{92,52,93,31,89,87,77,105}), Equals(V{105})); why not {92,93,89,87,105} ; first two elements: 92 is greater than 52 so is 92.

What I am missing?