I stopped when I read strcmp returns 0 if two strings are equal and 1 if they aren't.
It's sad how often you find the truth at the very bottom of a HN thread these days
[deleted]
C Strings and my slow descent to madness
241–250 of 329 posts
Re: C Strings and my slow descent to madness
#242Earlier quoted context omitted.
D's strings were defined to be UTF-8 back in 2000. wstring is UTF-16, and dstring is UTF-32. Back then it wasn't clear which encoding method would turn out to be dominant, so we did all three. (Java was built on UTF-16.) As it eventually became clear, UTF-8 is da winnah, and the other formats are sideshows. Windows, which uses UTF-16, is handled by converting UTF-8 to -16 just before calling a Windows function, and c…
What’s the ownership story for string views?
You can use automatic memory management and not worry about it. Or you can use D's prototype ownership/borrowing system. Or you can encapsulate them in something that manages the memory. Or you can do ownership/borrowing by convention (it's not hard to do).
Re: C Strings and my slow descent to madness
#243Pop 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…
> The delightful answer is none of them. No. Sorry. This is bad programming. C'mon. I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a ful…
One could take a glance at these and easily believe that they do the right thing. I don’t think that no one would accidentally miss such a small error from time to time.
Re: C Strings and my slow descent to madness
#244Earlier quoted context omitted.
Sort of unfortunate, because there's really no good translation for "hello" into Japanese - you'd say こんにちわ in the morning, in the afternoon こんばんわ and もしもし when answering the phone...
you'd say ohayogozaimasu in the morning, konnichiwa in the afternoon and konbanwa in the evening. I don't know how to type japanese on my phone, but the first is literally "early" surrounded by honorifics. The characters for konnichiwa means "this/now", "day" and the "wa" at the end is an article making the previous phrase the subject of the sentence. Same with konbanwa, but for evening instead of day. no idea on the…
According to an article I read, moshimoshi came from the telephone operators saying 申し申し (moushi moushi) to signify "I'm going to start speaking now". On a tangential note, 申し used to be the phrase when calling out to someone to ask something (similar to English "Excuse me").
Re: C Strings and my slow descent to madness
#245Earlier quoted context omitted.
I'm in the WG14 and my opinion is that there isn't one good way to do strings it all depends on what you value (performance/ memory use) and the usage pattern. C in general only deal with data types, north their semantic meaning. (IOW We say what a float is not what it is used for). The two main deviations from that are text and time and both of them are causing us a lot of issues. My opinion is that writing your own…
Has WG14 considered adding slices to C? [1] Introducing slices would naturally give way to a better string library. [1] https://www.digitalmars.com/articles/C-biggest-mistake.html
Its been 50 years so pretty much everything has been considered. In my opinion the mistake was not having arrays decay in to pointers but rather arrays should be pointers in the first place. An array should be seen as a number of values where with a pointer pointing at the first one. I think adding a third version of the same functionality would just complicate things further. (&p[42] is a "slice" of an array) Another thing I do not like about slices that store lengths, is that they hide memory layout from the user and that is not a very C thing to do.
Re: C Strings and my slow descent to madness
#246Earlier quoted context omitted.
Are you sure that strncpy does an out-of-bound write here? I believe it doesnt, but would give you an unterminated string in buf which is also... less than ideal (if the input is 80 non-null characters or longer).
Yeah, and I wouldn't say it's definitely unsafe. You can memchr a '\0' out of it (or not) to determine if a null terminator got in there or not.
I mean, you could but a lot of people do not. Plus, strncpy is terribly inefficient if the source string is tiny, because it’ll fill the rest of the buffer with NULs.
Re: C Strings and my slow descent to madness
#247"We're not in Kansas any more, Toto" Or to paraphrase that "We're not in Python any more, and C is not Python". You know what sends me insane? Indentation and lack of fixed types in Python. But I don't have problems with C strings. Because I have grown to love and know C's string foibles just like the author will certainly not be driven insane by 'Python's shortcomings according to me'. The world is full of people wh…
You've grown to love the footguns and hundreds of thousands of security holes that null-terminated strings have introduced over the decades? It's not so much a question of different is bad, it's that having one of the six positions for your car's stick shift be marked 'Self-destruct' is... Sub-optimal. I'm sure you're smart enough to operate that car safely, but the ditches seem to be filled with burnt-out husks. Tab…
> It's not so much a question of different is bad, it's that having one of the six positions for your car's stick shift be marked 'Self-destruct' is... Sub-optimal. I'm sure you're smart enough to operate that car safely, but the ditches seem to be filled with burnt-out husks.
Good analogy, but I think you're being to forgiving to C. It's more like having all 6 out of the 6 positions of your car's stick shift marked as self-destruct. If you don't want the car to self-destruct while changing gears, you need to tune your FM radio to 99.0 Mhz and quickly set your turn signals to left, right and left again before shifting. And that only works safely when shifting into the 1st, 2nd and 4th gears, unless you modify your car engine sot it can only drive on Microsoft roads.
Re: C Strings and my slow descent to madness
#248Earlier quoted context omitted.
I think this expectation doesn't vibe with my understanding of how people used to think about embedded or consoles. You shipped them and they were done. The games industry was also often trying to ship quickly. Small teams too. Latest tweaks to memcpy or fine tuning or revisiting the finer points of an already adequate SDK is low priority. By contrast, many more people are updating optimizations to GCC or clang for a…
You're probably right about consoles, and I was surprised to be wrong, but I checked, just to be sure. GCC and Clang are very nice compilers, but they are a different thing than the std lib. glibc, musl, the Windows C Runtime, iOS, Android, all have different implementations, sometimes outdated.
Gcc and clang are relevant here because memcpy is a builtin. It will not call libc for this.
Same is true of MSVC.
It's been that way on most modern compilers for about 20 years.
That's why I'm saying rolling your own may be futile. Compilers, not just libc, have paid a lot of attention to getting those things fast.
Re: C Strings and my slow descent to madness
#249K&R contains this beautiful koan-like string copy code: while (*t++ = *s++) ; Honestly the elegance of this thing was one of the hooks that made me fall in love with C. But this was from a now-forgotten age of innocence, as there are so many "nopes" around this line-and-a-half that one would, rightly, be tarred and feathered for ever putting it in a program today.
Could you explain why this line should be discouraged? I'm a beginner in C, so I really don't know. That's why I'm asking.
Equivalent of a strcpy() there's no bounds checking.
Re: C Strings and my slow descent to madness
#250The worst part of C strings is that they tend to show up in APIs (especially system calls). This make interoperability with other languages harder than it should m
This is why I hate them too. You can use a custom length + pointer type for representing strings in your own code, but interfacing with other libraries and the OS almost always requires having a null-terminated string. It forces you to make copies just to tack on the null terminator.