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.
C Strings and my slow descent to madness
321–329 of 329 posts
Re: C Strings and my slow descent to madness
#322Earlier 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…
Re: C Strings and my slow descent to madness
#323Earlier 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,…
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
#324Pop 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…
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
#325If 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…
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…
Re: C Strings and my slow descent to madness
#327Earlier 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).
Re: C Strings and my slow descent to madness
#328Earlier 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.
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
#329Earlier 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.
> 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?