Why there is so many functions in string.h library that are “not recommended for use”?

Question

There is something I try to understand about C origins, why there are functions that are not recommended for use in most of SO questions. Like strtok or strncpy , they are simply not safe to work with. Evrywhere I see recomendations to write my own implementation. Why wouldn't the standard change strncpy for example to BSD strlcpy , but is left instead with these "monsters"?

Answer 1

C is a product of the early 1970s, and it shows. Many of the iffier library functions were written when the C user community was very small and limited to academia, most of whom were experienced programmers.

By the time the first standard was released in 1989, those original library functions were already entrenched in 10 to 15 years' worth of legacy code (not the least of which was the Unix operating system and most of its tools). The committee in charge of standardization was loath to break the existing codebase, so those functions were incorporated into the standard pretty much as-is; all that really changed was adding prototype syntax to the declarations and changing char * to void * where necessary ( malloc , memcpy , memset , etc.).

AFAIK, only one library function has actually been removed from the language since standardization - gets . The mayhem caused by that one library call is scarier than the prospect of breaking what is by now almost 40 years' worth of legacy code.

Answer 2

There is a LOT of legacy "C" and "C++" code out there. If they removed all the "unsafe" functions from the "C" runtime libraries, it would be prohibitive for many developers to upgrade their compilers because all the old code wouldn't build any more.

Sometimes they will give "deprecated" compiler messages (MSFT is fond of this) so you will find and change to using the new, safer functions.

New code should use the "safe" functions, of course, but many of us are stuck with old compilers and legacy code to maintain :)

Answer 3

They still exist because of historical ancestral relationship with the "old system" / "codes" that still use them - ie to support "Backward Compatibility"

Own implementation is suggested to make the programmer use their own logic at their own risk as no one can know much better about their environment then the programmer himself, as for example, strtok is not thread safe.

Answer 4

It's all just dogma. Use the functions just be aware that they're indifferent to your goals in that they might not work in all circumstances (ie strtok and multi-threading) or they expect conditions to be caught before/after usage (ie strncpy and missing termination characters).