duplicate of this issue

Thank you for the response, sorry about that that's my first translation :)
I Removed comments and replace the placements.

I think Unnamed's explanation makes sense, though it is doubtful that one would ever need an array of all the integers from 1 to SIZE_MAX. But in any case it's too late to change the prototype now after so many completions. The function's contract has two much more serious flaws: allocating a heap array whereas the length is known in advance and an output parameter would be more idiomatic; and the completely redundant reporting of the length from inside the function. This is essentially an old, legacy C kata.

raised there as an issue

My main concern is with overloading the console output. It goes against the submission test guidelines.

Tests should not print excessively to standard output. Console output is limited to 1.5 MB and when the limit is reached, the test suite is aborted by the runner and marked as failed. Users sometimes debug their solutions by printing to stdout, and when the test suite itself uses up a significant fraction of the buffer, users may not have enough left for debugging. This especially applies to kata which output HTML to create some visualizations: such HTML uses up a lot of the buffer space allowed for stdout. Ideally, the test suite should give detailed output only when a test fails.

A fair compromise would be to revert the behavior of the submission tests while still printing the visualizations for the sample tests.

Done.

Done in this fork

Fixed.

Fixed.

😭

Approved with some adjustments after 9 years :-)

Seems like this note was already removed from description some time ago.

Thanks! Yeah, I lately can't be bothered too much about the includes, the linker solves it, but you're right.

You're right, random tests can generate 0 for every variable in TS. This seems to have been fixed for JS, but not TS :/ You should raise a new issue about this.

Edit: updated TS random tests to be in line with other languages (no more zeros :P)

I have done this today and am still getting random test cases with both speeds as 0 (in TypeScript)