Yep, everything is just so, I only would consider the {} formatting to be a terrible idea in terms of readability :)

de gustibus non est disputandum

And while on the subject, note that in the final result the binary() function proto formatting differs slightly from the other functions. For consistency, I'd declare all functions with spaces in the syntax and call them without.

@Edenia, I left it as you had it, but yes, it should be consistent.

Alright, let's say it's a matter of taste then. I still think there should be just one way of writing code. It's personally harder for me to read code with odd formatting. And by "odd" I mean different. If brackets are on one level, it's less motion for the eyes

You're right. Fixed now.

Also it probably worths pointing out that while I do program with most-recent compilers, I still write small programs compatible with older standards, when it wouldn't cost me much.

I noticed the code was missing a const in the declaration of ptr. That's fixed now and you should get no warning from your compiler.

“C is a strongly typed language”… Not by any common —or indeed any reasonable — definition of “strongly typed”. It is statically typed, but that's very different. And in fact C is infamously weakly typed.

stackoverflow.com/questions/430182/is-c-strongly-typed

@Edward Not sure what your point is, except that there's a lot of misinformation on the subject, by people who don't know type theory or compilers. By contrast, the creators of C themselves acknowledge that C isn't strongly typed. At any rate, even when taken at face value the link doesn't support your assertion.

@KonradRudolph The only point is that I am not looking for an argument.

Note that unsigned char mask = 0x80 introduces an assumption of CHAR_BIT = 8. That's possibly fine for a total beginner, when you're simplifying to normal modern machines, not the full range of C's portability. (Modern DSPs with word-addressable memory are an example of CHAR_BIT = 16, 24, or 32 that's still relevant.) @Edenia, I might go about it differently, starting from the end of a char buf[CHAR_BIT+1] buffer so I can use (c & 1) + '0' (assuming '0' and '1' have contiguous codes like in ASCII) and c >>= 1;. Like you would in asm for a non-power-of-2 base so you can only get LSD.

Or unsigned mask = 1U << (CHAR_BIT-1). (Note that can't overflow; if CHAR_BIT is huge, then unsigned is necessarily wide enough, so you don't need 1ULL like you would to safely do 1UL << 31.)

@PeterCordes what would you recommend as a practical alternative to 0x80 in the code above?

@Edward: I'd recommend unsigned mask = 1U << (CHAR_BIT-1) if you want to keep the rest of the code unchanged. That sets the bit at the MSB-position of an unsigned char. (unsigned char mask = same thing would be fine, too.) Or store digits into a buffer starting with the LSB at the end, like in my answer. (Not particularly better for source-level simplicity, but wasn't much worse and probably more efficient.)

@Edward If you're not looking for an argument then why do you try to argue when somebody points out that you've made a mistake? What do you think comments are for?!

I have changed "strongly" to "statically." The rest of the suggestion remains the same.

Why does the inner function take a pointer to a byte? Just pass the byte itself.

@JDługosz It could be done that way. I found this version more convenient, but I would not advocate strongly for either.

Please note that the comments are not meant to extend the answer, but to get clarification on the answer, that being said, if there is more information needed in the answer, please Edit it in and delete the comments or flag them for deletion to keep the answer clean and concise. Extended Discussion should be taken to a chat room.