Live data from Hacker News

C Strings and my slow descent to madness

deusinmachina.net

321–329 of 329 posts

Re: C Strings and my slow descent to madness

#321

Earlier quoted context omitted.

Of course I have data, do you think I am pulling benchmarks out of a hat? But I have not published those benchmarks, if this is what you're asking, the Nintendo thing I am afraid I cannot reproduce easily as I no longer have this devkit on hand. About the strlen benchmark, this is something I've done a few years ago, that could be easy to run again, but I am not sure this is worth the effort just to convince a random…

> do you think I am pulling benchmarks out of a hat? Yes. Share the data or you're spreading FUD.

You're being silly. Nothing they said was FUD, it was just a (not particularly controversial) anecdote

Re: C Strings and my slow descent to madness

#322

Earlier quoted context omitted.

Passing something that is not a string to strcpy or strlcpy is undefined behavior. They operate on strings, which are null-terminated by definition. On the flip side, strncpy operates on character arrays, which do not have to be null-terminated. (This is also why the output buffer is not always null-terminated: it's not meant to represent a string, despite the highly confusing str- prefix.)

Look at the declarations: char *strcpy(char *dest, const char *src); char *strncpy(char *dest, const char *src, size_t n); size_t strlcpy(char *dest, const char *src, size_t size); From that, how do you know that strncpy expects and produces a character array, strcpy expects and produces a string, and strlcpy takes either a character array or string and produces a string? Your descriptions of the string/character cop…

I don't disagree, although I would suggest using something other than strlcpy because it also may not do what you want.

Re: C Strings and my slow descent to madness

#323
post #319

Earlier quoted context omitted.

I did start with C at university, C and Scheme. We didn't go very in depth in the "defensive programming" part, especially with C. We talked a bit about safety when we were doing web and database stuff, but I think that's it. I am pretty lucky, one of my friend is in cybersecurity, another is very good with C, and there are lots of people online freely sharing their knowledge, so at least I kind of know what I don't…

> On one hand, I understand that blaming the tool isn't a good attitude to have. On the other hand, my job consists in building tools for other professionals, and I feel like I have way higher standards for the tools that I produce compared to the tools that I use. I think your view is of this is reasonably balanced. There is that element of someone without extensive experience not knowing what they don't know. Well,…

That is a good point, we've never had so much information accessible. On the other hand, it's sometimes hard to know what actually matters. Maybe we (or I) don't know how to fully tap into its potential, but I still feel that I progress way faster when I can talk to someone that has experience. I can access their knowledge, but I can also start to see how they think, how they approach problems, how they solve them, what they value.

I've also heard that for them, it can be valuable to have someone with a fresh outlook on things. You notice things that people got used to, and most of the time things make perfect sense considering the situation, but sometimes there's an opportunity to improve things for the better.

You're right about learning, it's a lifelong process. I do think that doing this along other people helps. Sometimes working on something by yourself can be quite lonely, especially if the people around you are not that much into all of that. That kind of loops back into the discussion about tool. Blaming your environment is counterproductive, but it's still important to pick it carefully.

Re: C Strings and my slow descent to madness

#324

Pop quiz, which of these is safe, given "char buf[80]" and arbitrary user input in argv[1]? gets(buf); scanf("%s", buf); strcpy(buf, argv[1]); scanf("%80s", buf); strncpy(buf, argv[1], 80); snprintf(buf, 80, argv[1]); ---- The delightful answer is none of them . The first three have no bounds checking at all, meaning that they will happily overflow the buffer to an arbitrary extent (gets, at least, will usually trigg…

> C string handling practically invites off-by-one errors and horrible security practices out-of-the-box.

At that point it is beating dead horse - it is such well known fact how C strings works. And it's insanity that noone proposed new standard library with better implementation for strings domain. Boo hoo "old programs" bla bla...

And it's total insanity to blame powerfull language for allowing you to do almost anything in it. You don't even need to ask commitee for permission to roll your own _low level constructs_ - how insane is that ? ;)

But keep spitting on what gives you freedom...

Re: C Strings and my slow descent to madness

#325

If 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…

"If 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." unsigned int str_len(const char *s) { register const char *t; t = s; for (;;) { if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; if (!*t) return t - s; ++t; } } I still use this instead of stdlib strlen. Of course I also use software everyday that…

Something worth considering: Sometimes people may use older versions of compilers, e.g., older versions of GCC, for compiling older programs for older hardware. These GCC versions are smaller in size and written to run on less powerful hardware. For example, the gzip'd source tarball for GCC 2.95 from 2001 is 12M while the one for GCC 12.2 from 2022 is 143M, an 11x size increase.

Re: C Strings and my slow descent to madness

#326

> By default, Windows PowerShell .lnk shortcut is hardcoded to use the "Consolas" font Surely this is not the case for Japanese versions of Windows (or users with Japanese set as their display language?)

Yes, you can actual look at the full list from `HLKM\Software\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont` (taken from my copy of Windows 10, bracketed comments mine): 0 Lucida Console 00 Consolas 932 *MS ゴシック [MS Gothic for Japanese] 936 *新宋体 [Simsun for simplified Chinese] 949 *굴림체 [Gulimche for Korean] 950 *細明體 [Windows MingLiU for traditional Chinese] Note that there are actually two global defaults…

Japanese versions use CP932 though, which according to your list would use a font that's not Consolas (MS Gothic in this case).

Re: C Strings and my slow descent to madness

#327

Earlier quoted context omitted.

Yes, you can actual look at the full list from `HLKM\Software\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont` (taken from my copy of Windows 10, bracketed comments mine): 0 Lucida Console 00 Consolas 932 *MS ゴシック [MS Gothic for Japanese] 936 *新宋体 [Simsun for simplified Chinese] 949 *굴림체 [Gulimche for Korean] 950 *細明體 [Windows MingLiU for traditional Chinese] Note that there are actually two global defaults…

Japanese versions use CP932 though, which according to your list would use a font that's not Consolas (MS Gothic in this case).

I should have said "no" in place of "yes" (being a non-native speaker, I completely overlooked "not" in your original reply), otherwise I believe I didn't contradict you.

Re: C Strings and my slow descent to madness

#328
post #222

Earlier quoted context omitted.

They don't own anything. It's just a pointer and length. They don't allocate/deallocate.

I mean clearly something needs to own the buffer for a new string.

Sure, but that's not the string_view's problem, you can't just make string_views, the string you want to borrow a view into needs to exist first.

Imagine you go to a library and insist on borrowing "My Cousin Rachel", but they don't have it. "Oh I don't care whether you have the book, I just want to borrow it" is clearly nonsense. If they don't have it, you can't borrow it.

Re: C Strings and my slow descent to madness

#329

Earlier quoted context omitted.

I mean clearly something needs to own the buffer for a new string.

Sure, but that's not the string_view's problem, you can't just make string_views, the string you want to borrow a view into needs to exist first. Imagine you go to a library and insist on borrowing "My Cousin Rachel", but they don't have it. "Oh I don't care whether you have the book, I just want to borrow it" is clearly nonsense. If they don't have it, you can't borrow it.

Walter is talking about D, and he said this:

> D doesn't distinguish between a string and a string view.

In C++ std::string owns the buffer and std::string_view borrows it. If there is no difference between the two in D, then how is this difference bridged?

Post reply on HN