Except strlen, though I guess you can replace with memchr in C11.
-
-
Replying to @RichFelker @0xabad1dea
Ok, fine, you can have `str[n]len`. But that's it.
1 reply 0 retweets 1 like -
Replying to @stephentyrone @0xabad1dea
strstr, strchr, ... - basically all the ones only taking const char * are fine.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @0xabad1dea
No. str[n]len for conversion from legacy NUL-terminated strings, and then everything is explicit-length beyond that boundary.
1 reply 0 retweets 2 likes -
Replying to @stephentyrone @0xabad1dea
Going to disagree on null-termination being legacy. In many places it's safer, & of course simpler. And its a public contract outside C (pathnames etc.).
1 reply 0 retweets 0 likes -
Replying to @RichFelker @0xabad1dea
I don’t think that it’s actually safer, and I know that it’s always less efficient.
2 replies 0 retweets 1 like -
Replying to @stephentyrone @0xabad1dea
Base,len pair is more versatile/powerful (use substr in-place) & may be more efficient, but also subject to error using wrong len.
3 replies 0 retweets 1 like -
Personally I prefer null-terminated as public interface except in special cases where it's inefficient, base+len internally where it helps.
1 reply 0 retweets 0 likes -
If public API allows base+len, you risk the possibility of internal nul bytes which will be dangerous if you use the string in pathnames & other similar contexts.
2 replies 0 retweets 0 likes -
Replying to @RichFelker @0xabad1dea
Pathnames and the like should usually be getting sanitized/normalized anyway, checking for nul should be part of that, no?
2 replies 0 retweets 0 likes
Yes but the check has to happen before it passes to code using C strings... Lots of room for programmer error.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.