C Strings and my slow descent to madness

Post by 1vuio0pswjnm7 » Fri, Apr 07, 2023, 1:28 AM UTC

1vuio0pswjnm7 wrote: post #141

stephc_int13 wrote: post #31

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…

Post by nneonneo » Fri, Apr 07, 2023, 1:30 AM UTC

myrmidon wrote: post #210

nneonneo wrote: post #202

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…

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).

Post by saagarjha » Fri, Apr 07, 2023, 1:36 AM UTC

PaulDavisThe1st wrote: post #133

zh3 wrote: post #107

I once got called in to fix an SS7 stack suffering from poor performance. Pretty well written, and not obvious at first sight why it was going slow. Most of it was low-level bit fiddling, and some small strncpy's() - generally about 8 chars or so. Didn't take that long to profile (well, printf's as no profiling available) and figure out it was the strncpy's causing the problem, but why? Well, there was a handy 8 mega…

The appearance of strncpy() in any source code is an immediate panic attack for me. It should never be used, and if it is used, it should be removed. Similar rule for sprintf(), all instances of which should be replaced by snprintf().

Post by counttheforks » Fri, Apr 07, 2023, 1:38 AM UTC

stephc_int13 wrote: post #183

asveikau wrote: post #179

Earlier quoted context omitted.

Nintendo DS has probably had a lot less scrutiny than a major libc or recent GCC or clang [though you can probably target its ARM processor with that]. Also, for an older embedded platform they may choose to do optimization for code size rather than cycles or clock time. I'm going to have to doubt the start of your comment. Having seen a lot of libc implementations I think you are better off not wasting time optimizi…

On the contrary, I expected the Nintendo DS SDK to be well optimized, performance of memcpy can be critical on such a constrained hardware. And it was optimized, just not with the best tricks. I got the prefetching trick from Intel source code, except that I replaced the PLD instruction by a simple dummy load. And about strlen, you'd be surprised, some implems are very good, and some are not, depends on the compiler…

Post by saagarjha » Fri, Apr 07, 2023, 1:39 AM UTC

benmmurphy wrote: post #48

`strlcpy` is the function you probably want. but again it is not standard. https://lwn.net/Articles/507319/ I think the reason people don't want to standardise this kind of function is it often gives wrong behaviour. for example if you are trying to copy a string into a fixed buffer and its too long then often it is an error or potentially even a security bug to truncate it. so these functions generally do the 'wrong…