The struct maybe_double is a way to return both conversion status and result at the same time. The field value_exists means that the input string was successfully parsed. If it is true, then the conversion succeeded and the result is inside the field value. If it is false, then the input string was not a representation of a float (and the field value is ignored).

Maybe a bit the other way round: calloc is something like a combo of malloc and memset to 0.

Since your question seems to be answered, let me mark it as resolved.

Your solution does not put null terminator in the output buffer. Upon a call to your function, output buffer is allowed to have any content, it's responsibility of your solution to null terminate it properly.

Remember that you can always ask for help on kata solving help Gitter channel. You can ask questions related to kata algorithm, language, some specific part of the task, whatever, and someone will eventually help.

Okay, now I see where you are coming from. You are just discouraged by the fact that 8 kyu kata requires so much work and prerequisite knowledge in C. This is, unfortunately, true, and it's a result of a couple of factors coming together.

Some kata are created in high level languages (like Python or JS), get ranked as trivial, entry level task at 8 kyu, and some time later they get translated to low level language, like C. All language versions are ranked the same, but it;s true that because of how arrays are handled in C, it requires more work. Inconsistent difficulty between various language versions of one and the same kata is a known problem, but there's yet no agreement how to handle it. This is the main reason why sometimes you need some kowledge about memory management, pointers, arrays, and such, to solve C kata even when ranked as trivial.

Kata authors and translators also are at fault here. It's kind of a pattern in CW kata that if solution has to return a pointer or an array, it's required to allocate the memory. It is not a valid C pattern, or maybe it's not a pattern which is valid in many scenarios, but translators seem to not know anything better, so they go the way they know. With a very few active C authors it became a kind of a pattern for all C kata, that details on memory management are not given at all, and you are required to allocate the mmeory by yourself even it would not be the best way to handle such scenario in C in "real world". I generally regard such lack of specification as kata issue and I usually raise it as a remark when I get to seeing the translation before it gets approved. If you think there's not enough information, you can raise an issue or suggestion, so author would add required information to description or some hint to sample tests. "Hints" section should generally not be necessary, everything should be clearly spelled out in the task.

First of all, it's not really clear what you are asking.

Second, your rant seems to be somewhat... surprising. Because of two reasons.

Your conclusion is actually pretty correct and that's exactly how it's supposed to be. Comparing Python to C is like comparing apples to orange stem cells. C is low level, and it's difficult to get things working. Python is exactly opposite end of the spectrum, it's high level, and that's exactly why it exists: to make things easy.

Without seeing your code it's difficult to say why you were getting crashes, but it's most certainly some problem with your code. printf works perfectly well here, I had no trouble with printing size of the array using following code:

int *difference_in_ages(size_t a, const int ages[a]) {

  printf("%zu", a);
  return malloc(sizeof(int));    

}

Note that requirement of returning some allocated memory is because how test cases are created. Properly created test suite would work and would not crash if solution stub would return, for example, NULL.

My question would generally be: if you can't handle low level, why would you even bother solving kata in C?

I think I found at least the (critical) bug in your code. When you initialize dupes, you do not overwrite the memory landscape with null pointers. Later, when you run the strchr function, it sometimes could find uppercase letters within that memory range, and so your results would not count those legit dupe chars. So to avoid this undefined behavior always zero out such a data type at its initialization.

I tested the first bin's code and it is passing all tests.

If it's your code, just post as a question, not as an issue. It's hard to say what's up without seeing your code, so if you want you can post it with proper code markdown, and don't forget to use the spoiler tag. I can take a look and maybe help you along.

It is possible that you get nothing printed, and there are many possible reasons for that in C. Without seeing your code it is difficult to say what's wrong with it.

One possibility is that your solution crashes, and all non-flushed output gets lost. Adding some explicit flushing could help. But as I said, without seeing the failing code it's just guessing.

#include <stdio.h>
#include <stdlib.h>

char *alphabet_position(char *text) {

  printf("%s", text);
  return "12";

}

Doesn't that work?

The 'numbers test' in C has strings made out of ASCII numbers that are randomly generated. This is tested for the fact that numbers or non-alphabet characters should be ignored in the function. If you're geting 15 lines of 10 random numbers from printf() or puts(), everything's alright.

Note that sample tests for C have two groups: "should_pass_all_the_tests_provided" with some sentences, and "number_tests" with strings which contain all numbers. Make sure that what you consider "garbage" is not an actual test case. Note how this code does not crash and prints inputs as expected:

#include <stdio.h>

char *alphabet_position(char *text) {
  puts(text);
  return calloc(1, 1);
}

Edited my previous answer.