Brain fart on my end. I initially wrote the tester and used const int for the index n to ensure it wouldn't be modified within the scope of the tester. I carried over that same approach to the function definition, but you're right — since n is passed by value and not by reference, making it const doesn't serve any purpose in the function prototype.

I've corrected the prototype based on your suggestion!

Prototype should not use const int, that makes no sense at all.

merged!

Fork with a fix: https://www.codewars.com/kumite/66d83be47ec93e3c7f46e5c2?sel=66d83be47ec93e3c7f46e5c2

Test suite and Sample tests give warnings to stderr:

fixture.c:19:15: warning: incompatible pointer to integer conversion initializing 'const int' with an expression of type 'const char *' [-Wint-conversion]
    const int expected_offset = expected - start_address;
              ^                 ~~~~~~~~~~~~~~~~~~~~~~~~
fixture.c:20:15: warning: incompatible pointer to integer conversion initializing 'const int' with an expression of type 'const char *' [-Wint-conversion]
    const int result_offset   = result   - start_address;
              ^                 ~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.

This challenge gives me terrible flashbacks from times when I did not understand C well, and had to use the lpstrFilter of the OPENFILENAME structure and could not get the embedded zeros to work. Great times.

Ha, my idea for C++ translation was different: use std::string, which would possibly show how zeros can be legally embedded in a C++ string, and maybe show how the implicit zero at the end works. I think that creating a C++ translation only to use C-style pointers is not very helpful, but if you guys think it would be good, than okay :)

Anyway, I'm going to approve this one.

EDIT: with votes of 11x7kyu and 2x6kyu, approved as 7 kyu.

The Kata has been updated according to your suggestions. Thanks for your input!

Ah, okay.

Yeah from the solver's side it should def be kept as pointers, but probably from the random tests it would have to be a std::string (with the .c_str() ptr being what is provided to the user); I was talking about the logistics of that part of making the Kata.

@o2001 I think while translating this specific kata to C++ it happens to be one of these cases where it would be better to just keep the signature it as is. After all, C++ does have null-terminated strings, and this kata is focused primarily on them, not strings as a concept in general.

Also, we have this kata, which is specifically made for C and descendents of C. I think if following the example and adding something about C in the title would help to avoid this problem.

Unless I'm wrong, I believe this Kata is adaptable as-is into C++, from the solver's side at least. While the constructor of std::string stops at the first null terminator it encounters, you can still place null characters in it after constructing. That, or you can construct the string with spaces as placeholders then do a simple std::replace to change the spaces to null characters. There is also std::string_view as an option for this case

Just yell at people for translating to any language that has no null-terminator and reject, as we already do with BF translations

I want to approve this challenge but i am not sure how to prevent translations to irrelevant languages. Would anyone have any idea? What would the relevant languages even be? Embedded zeros in a C++ string are something different than in a C string, but I believe still interesting. It can be fun in assembly languages too. But any others? Or maybe it does not matter too much? What do you people think?