[Gibbon1]

> rewriting those functions would be destructive

Getting rid of standard string functions would be the best thing to happen to the c language in the last 25 years.

There are two types of c programs. Those that scrupulously avoid standard string functions and brittle programs shot through with security holes.

[kbenson]

At the point when you have to convert between string types and can no longer easily use much of libc without conversions, why not just use a different language that's already gone much farther in the name of safety, usability or other features?

In other words, if your pseudo-c candidate already suffers from most the interop problems that Rust, D, Nim and Go do, why not just use one of those and at least reap the other benefits they provide?

[watersb]

Anything to help legacy C code base is welcome. Hard part is knowing whether touching decades-old, tested code is worth the risk.

[peterevans]

I mean, I guess it's the best thing if you want to wreak havoc and chaos? Which, perhaps, you do!

Your suggested dichotomy is, of course, a little bit false. But I'm sure you knew that when you wrote it down.

It's entirely possible to write secure programs in C, even with standard functions. Writing your own code does not somehow confer a level of security-consciousness that you lacked when sticking to strings.h. (It does give you a wonderful opportunity to write your own security holes that no one has discovered yet!)

I mentioned this somewhere else, but we're in a pretty good place right now with languages; we finally have really solid alternatives to C that can compile to machine code, in both Go and Rust.

[Gibbon1]

> It's entirely possible to write secure programs in C, even with standard functions.

You realize that most standard string functions are outright banned by organizations that care about security. As in you're not allowed to use them not even if you pinky swear to be 'careful'

https://msdn.microsoft.com/en-us/library/bb288454.aspx