It was a design decision of QNX that the kernel never uses strings. Everything the kernel handles is fixed length, except messages, and messages go from one user process to another. The kernel does not allocate space for them. I think they go that right.

There's a QNX user process that's always present, called "proc", which handles pathnames and the "resource managers", programs which respond to path names. But that's in user space, and has all the tools of a user-space program.

Most of the code I write has a spec of input and output being some form of text. Still, I tend to write that in languages that have safe string handling and drop into C only when the profiler indicates that's useful.

When handling strings in C, it's useful to use the string functions from glib or pull in one of the specifically safe string handling libraries and not use any C stdlib functions for strings at all.

There are a number of C strings libraries safer to use than the standard library, and many of them are simpler, more feature-rich, or both.

* https://github.com/intel/safestringlib (MIT licensed)

* https://github.com/rurban/safeclib (MITish)

* https://github.com/mpedrero/safeString (MIT licensed)

* https://github.com/antirez/sds (BSD 2-clause, and gives you dynamic strings)

* https://github.com/maxim2266/str (BSD 3-clause)

* https://github.com/xyproto/egcc (GPL 2.0, includes GC on strings)

* https://github.com/composer927/stringstruct (GPL 3.0)

* https://github.com/c-factory/strings (MIT licensed)

* https://github.com/cavaliercoder/c-stringbuilder (MIT licensed, does dynamic)

If one does use the C standard library directly for handling strings, the advisories from CERT, NASA, Github, and others should be welcome advice (CERT's advice, BTW, includes recommending a safer strings library right off).

Yes, sure, write Unix CLI plumbing tools without strings.

Until you want to communicate with the user, filesystem, or web.