> strcmp takes two strings and returns 0 when they are true.
ITYM “equal”, not “true”.
C Strings and my slow descent to madness
81–90 of 329 posts
Re: C Strings and my slow descent to madness
#82[dead]
Re: C Strings and my slow descent to madness
#83It's unfortunate the author put the arrays-are-pointers thing so early in the doc, as that's a very beginner-to-C mixup and really nothing at all to do with strings. Otherwise, yep. It's pretty bad. C is a great language, but its string handling is definitely garbage. You get used to it pretty quick, and it's not hard to write a handful of sane wrappers or a simple string library for your own use, but the standard li…
This is almost a cliche among many C language lawyers and/or Stack Overflow answer-rich people and I know you mean well, but: arrays are not pointers.
In some contexts, the name of an array decays to a pointer to its first element. That is a better way of putting it, and it's a (much) weaker statement.
Edit: if they were the same, this code:
int foo[] = {1, 2, 3};
int *bar = foo;
printf("%zu and %zu\n", sizeof foo, sizeof bar);
Re: C Strings and my slow descent to madness
#84I don't use null terminated strings. ptr+len struct everywhere. And when I need to call an API, like fopen, I make a temporary copy of that string + the null termination, do my work and then free it. You can printf non-null terminated strings too. Check printf("%.*s", length, strptr).
> You can printf non-null terminated strings too. Check printf("%. s", length, strptr).* I haven't checked yet, but I'm about 90% confident that's UB. Is printf() guaranteed not to read to the end of the string when you give it a length?
Won't read a single byte beyond the length you give it.
And this is a standard practice in libraries for printing pre-determined lengthed string.
Re: C Strings and my slow descent to madness
#85If you are using C and do some non-trivial work with strings you should either use a good library to handle strings or build your own. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…
Is your framework open sourced?
Not 100% decided yet, but it is very probable that I will open source it.
Re: C Strings and my slow descent to madness
#86> So how can we handle this case safely? There are a few ways I can think of.
strdup:
> The strdup() function returns a pointer to a new string which is a duplicate of the string s. Memory for the new string is obtained with malloc(3), and can be freed with free(3).
Re: C Strings and my slow descent to madness
#87> If we try to print out some Japanese characters… [] The output isn’t what we expect. Yes it is. And I bet on a modern windows version it is too. The terminal has been (probably intentionally) neglected by ms for a long time, but as far as I know this has mostly been fixed on modern windows versions. EDIT: Author admits it later in the text "will be fixed in Windows 11 and Windows Server 2022" Also it says "strlen("…
> The terminal has been (probably intentionally) neglected by ms for a long time, I don't think it is an intentional lack of care, just a lack of care. Internally MS devs affected by the appalling state of the console just did what the rest of us did and installed an alternative. > but as far as I know this has mostly been fixed on modern windows versions. Ish. The default console for powershell is better, but a lot…
> you might be thinking are in there are in fact only in Windows Terminal
A lot of those changes are in ConsoleHost, so Windows 10 and 11 get those improvements (like VT100 sequences) in cmd.exe as well
Re: C Strings and my slow descent to madness
#88If you are using C and do some non-trivial work with strings you should either use a good library to handle strings or build your own. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…
> especially on the memory management side.
Libc string functions don't manage memory. They can be used no matter where your strings are stored. It is more of a choice between generality vs convenience in common cases.
Re: C Strings and my slow descent to madness
#89C strings are bad for sure. Consider those raw assembly. Instead of using it directly get some decent string library ASAP and use it exclusively.
They are just arrays, like everything else in the language. If you don't want to manage plain arrays, better look for a different language.
they are not "just" arrays, they are arrays with a null-terminated expectation. Most of the time. The lack of consistency and difficulty communicating the expectations is what is hair-pulling in C, and that's on top of the difficulty of communicating the difference between an array and a pointer in C.
Re: C Strings and my slow descent to madness
#90If you are using C and do some non-trivial work with strings you should either use a good library to handle strings or build your own. It is not that difficult in practice. The old C std lib is, in my opinion, outdated, obsolete and a very bad fit for complex string handling, especially on the memory management side. In my own framework, the string management module is using a dedicated memory allocator and a "high l…
> the C std lib is the weakest part of the C language and it should only be used as a fallback.
I've been musing for a while now: what would it look like if we were to discard the C library and design a new one, leaving the language itself intact?