I don't know what'd be a better replacement; it depends so much on the use case. I'd say there is no one-size-fits-all solution to string handling in C. For most code which occassionally deals with strings but isn't really focusing on text, the usual standard library functions and BSD extensions are just fine. I mean malloc, free, strdup, strlcat, strlcpy, strchr, strstr, snprintf, and so on.

For my code editor, I wrote my own dynamic text buffer with the goal of supporting large files with binary data in it. This is highly application specific code and wouldn't make a good general purpose string library.

I skimmed through the bstring code long ago, and I recall seeing quite a bit of questionable or hairy code. But abusing undefined behavior for security purpose was the final stake so I gave up and decided I do not want to use or endorse that library. Also, using ints for string lengths is just stupid if your code ever has to interact with the outside world. Why does bstring do this?

EDIT: Actually, let me just quote the (in)security statement here:

> Bstrlib is, by design, impervious to memory size overflow attacks. The reason is it is resiliant to length overflows is that bstring lengths are bounded above by INT_MAX, instead of ~(size_t)0. So length addition overflows cause a wrap around of the integer value making them negative causing balloc() to fail before an erroneous operation can occurr.