James Antill writes about C string libraries, HTTP servers, and network I/O, based on his Vstr and ustr libraries and the and-httpd server.
HN links it in discussions of C string APIs, where commenters compare Vstr and ustr with alternatives like Sds and note Vstr was last updated in 2006.
People have been complaining for years now about C stile strings (that have been widely used for decades now). But nobody ever did anything about it ?
There have been many efforts (http://www.and.org/vstr/comparison), but ultimately they all failed to find widespread adoption because they're solving the wrong problem.
For any non-trivial data munging operation experienced C programmers quickly ditch C strings in favor of vectors.
The simplest approach employs a simple pointer and length (or boundary) tuple; i.e. a vector. You can get fancy by wrapping them in a struct, but even that isn't necessary and, especially wrt API design, often needlessly forces interface users to create temporary "slice" objects with an annoying type peculiar to the interface. Newer languages offer nicer interfaces for slices, but simple pointers are hard to beat in terms of simplicity and usability. (The only problem with simple pointer derivation and manipulation a la C is that they're difficult for a compiler to both verify the correct use of _and_ to aggressively optimize. You must choose one or the other. Requiring the user to use specialized, compiler sanctioned primitive aggregate types in languages like Rust is a way to meet the compiler half-way.)
Also, for complex parsing tasks experienced C programmers will often code a straight-up state machine, or leverage a parser generator. In both cases C-style NUL terminated strings aren't even visible in the rearview mirror.
IME, I've found…
Sadly there's nothing official for HTTP. This strikes me as a bit daft, because the spec allows a surprising amount of leeway, and there's actually a surprising amount to it in terms of annoying fiddly syntax. (I have no idea in whose interests this is intended to be, because both client and server have to both read and write this stuff. If they'd decided to make one case complicated so the other could be simple, that would be understandable, if barely less annoying.)
And-HTTPD comes with some test data: http://www.and.org/and-httpd/ (I've not looked into this in any depth, except to note its existence, but I wish I'd seen it when I was working on my server. The chap also has an amusing page about the HTTP spec, which I basically agree with: http://www.and.org/texts/server-http)
For Web Sockets, there's a good test suite here, but again, it's not official: http://autobahn.ws/testsuite
Yes, strcpy is almost universally understood as a security problem. In fact, here's a nice regex to apply to some C code to find buffer overflows:
LC_ALL=C egrep '[^_.>a-zA-Z0-9](str(n?cpy|n?cat|xfrm|n?dup|str|pbrk|tok|_)|stpn?cpy|r?index[^.]|a?sn?printf|byte_)' src/*.c
Taken from the really well researched and secure andhttpd:
http://www.and.org/and-httpd/#secure
Run that regex on some C code, then go look at how the inputs to those functions are used, and then you can probably create some of your own buffer overflows. It's like magic.
Sds from Antirez has a lot of the same features (not all), and is kept updated since it's used by redis and other projects. https://github.com/antirez/sds/blob/master/README.md
Vstr appears to have last been updated in 2006. It does have a comparison of different string libraries, though that's also dated: http://www.and.org/vstr/comparison
If the claim is random access, then I agree that O(1) is imposssible. Rope would allow these tasks to be carried out in logarithmic time.
The tasks I chose were the first two API desiderata from http://www.and.org/vstr/design - which is the examples page you had in mind?
Almost certainly D. J. Bernstein's string API from daemontools , http://cr.yp.to/daemontools.html and his other bits of code. Some commentary at http://www.and.org/vstr/comparison . Probably more commentary elsewhere.