While I agree code like this shouldn't be released fail-deadly it's also patently obvious it's not to be used. There is sufficient notice in the README. If someone uses this, it's at their own peril.
Would you make the same argument for reference implementations of algorithms? For example, small details leading to bugs that can be compromised?
At some point people have to be responsible for themselves...
It always tickles my brain when I see "zero-dependency" or "no dependency" and then the first thing in a project is a bunch of include statements. Don't understand me wrongly, the includes by themselves don't strike me as a bad thing! I just sometimes wonder whether it's a me-thing or whether other people are wandering off to the question 'what is a dependency' as oft as I do :)
They are all standard headers, required in a hosted implementation of ISO C. Only stripped down C implementations which the standard calls "freestanding" can omit parts of the standard library.
Except for <stdint.h>, all existed in 1989 ANSI C; though not with all the content they have now.
If you write a C program, you have a dependency on a C implementation; it's not going to compile itself. That's an external dependency: something not in your program. It is a second party dependency. First party is you, second is the programming language and library (and perhaps the platforms you are targeting and what they supply). Third party external dependencies are anything not in your program or language implementation or platform. The things you have to tell the user to download and install, possibly from source.
One second-party dependency this code has is on a Windows-like command interpreter which provides a "cls" command, for the several system("cls") calls the code makes to clear the screen.
I do know about the ISO C standard, I was actually more intending to refer to the fact that, even though there exists a well defined standard, there may be implementation differences in the libc variants you compile against, certainly in certain UB-areas. I probably should have made that a bit more clear, because I didn't actually make that point at all. Excuses for the bad formulation of my thoughts.
Yes, a program can have a second-party dependency in the form of invoking some implementation-defined behaviors or undefined behaviors that de facto work, not just a dependence on the simple existence of something without which the program doesn't build.
We can't infer a dependence of that kind from seeing standard header includes. That does not raise the suspicion above background levels.
If you have a char array[] that can hold arbitrary binary data, some of the values can be negative, since char is usually signed. isapha(array[i]) is undefined behavior if array[i] is a negative value other than EOF. If it doesn't crash, it will likely index backwards into a lookup table and access garbage.
EDIT: I see from the dead reply that this is a bot, or a "vibe coder" who doesn't understand the code. The bizarre remark "<ctype h> is solely to allow me to define structs using typdef" is nonsensical. Whoever (or whatever) wrote the code understands that <ctype.h> provides functions like isalpha and is unrelated to defining C types.
I'm 100% human, but also 100% amateur. Until 5 minutes ago, I understood <ctype h> to be necessary for me to use typedef to enable me to refer to structs by an alias, instead of writing "struct"! The perils of being self-taught. Now I can see the only errors thrown up when I remove the include are isdigit and isalnum! This is why I posted on HN!
EDIT: I think I can fix the isalnum bug risk that you identified by checking that the value of the ch variable in the get_string_input function is non-negative before allowing it to be appended to str.
Thanks, this is the kind of feedback my hobbyist ass needs. My intention in including <ctype h> is solely to allow me to define structs using typdef. I'm not aware of any crashes or compiler warnings caused by the potential abuse, but I'm going to look at it later.
Get rid of the non CSPRNG function. Someone will use this to store coin and get robbed. Non-csprng has no place in this tool
While I agree code like this shouldn't be released fail-deadly it's also patently obvious it's not to be used. There is sufficient notice in the README. If someone uses this, it's at their own peril.
Would you make the same argument for reference implementations of algorithms? For example, small details leading to bugs that can be compromised?
At some point people have to be responsible for themselves...
It always tickles my brain when I see "zero-dependency" or "no dependency" and then the first thing in a project is a bunch of include statements. Don't understand me wrongly, the includes by themselves don't strike me as a bad thing! I just sometimes wonder whether it's a me-thing or whether other people are wandering off to the question 'what is a dependency' as oft as I do :)
They are:
They are all standard headers, required in a hosted implementation of ISO C. Only stripped down C implementations which the standard calls "freestanding" can omit parts of the standard library.Except for <stdint.h>, all existed in 1989 ANSI C; though not with all the content they have now.
If you write a C program, you have a dependency on a C implementation; it's not going to compile itself. That's an external dependency: something not in your program. It is a second party dependency. First party is you, second is the programming language and library (and perhaps the platforms you are targeting and what they supply). Third party external dependencies are anything not in your program or language implementation or platform. The things you have to tell the user to download and install, possibly from source.
One second-party dependency this code has is on a Windows-like command interpreter which provides a "cls" command, for the several system("cls") calls the code makes to clear the screen.
I do know about the ISO C standard, I was actually more intending to refer to the fact that, even though there exists a well defined standard, there may be implementation differences in the libc variants you compile against, certainly in certain UB-areas. I probably should have made that a bit more clear, because I didn't actually make that point at all. Excuses for the bad formulation of my thoughts.
Yes, a program can have a second-party dependency in the form of invoking some implementation-defined behaviors or undefined behaviors that de facto work, not just a dependence on the simple existence of something without which the program doesn't build.
We can't infer a dependence of that kind from seeing standard header includes. That does not raise the suspicion above background levels.
You should also complain that it depends on having a computer while you are at it.
There are plenty of platforms that don't have a stdlib available.
You're right. I should have said no dependencies other than standard C libraries. I meant no big ones like SSL, GMP, etc.
It looks like you might be abusing <ctype.h>
If you have a char array[] that can hold arbitrary binary data, some of the values can be negative, since char is usually signed. isapha(array[i]) is undefined behavior if array[i] is a negative value other than EOF. If it doesn't crash, it will likely index backwards into a lookup table and access garbage.
EDIT: I see from the dead reply that this is a bot, or a "vibe coder" who doesn't understand the code. The bizarre remark "<ctype h> is solely to allow me to define structs using typdef" is nonsensical. Whoever (or whatever) wrote the code understands that <ctype.h> provides functions like isalpha and is unrelated to defining C types.
I'm 100% human, but also 100% amateur. Until 5 minutes ago, I understood <ctype h> to be necessary for me to use typedef to enable me to refer to structs by an alias, instead of writing "struct"! The perils of being self-taught. Now I can see the only errors thrown up when I remove the include are isdigit and isalnum! This is why I posted on HN!
EDIT: I think I can fix the isalnum bug risk that you identified by checking that the value of the ch variable in the get_string_input function is non-negative before allowing it to be appended to str.
Thanks, this is the kind of feedback my hobbyist ass needs. My intention in including <ctype h> is solely to allow me to define structs using typdef. I'm not aware of any crashes or compiler warnings caused by the potential abuse, but I'm going to look at it later.