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 -
Assuming the two are wrapped together in one struct, how do you mess it up
1 reply 0 retweets 2 likes -
That is a good approach to avoid human error but at some point you need to unpack & use the values, & it's easy to accidentally write bar.base but bah.len, etc.
1 reply 0 retweets 0 likes -
unsubscribe
1 reply 0 retweets 2 likes
Will do. Wasn't sure if continuing this would be interesting to you or not.
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.