Why didn't gcc implement _s functions?

Question

_s functions, such as scanf_s, printf_s seems to be optional standard. MSVC has implemented these functions, but gcc hasn\'t.

Is there spec

Answer 1

The _s functions are optional (Annex K of the C11 standard). They're widely regarded as 'not very beneficial'.

In the answers to my question Do you use the TR-24731 "safe" functions?, you can find information about where there are problems with the standard specification — such as crucial differences between the standard and Microsoft's implementation. TR 24731-1 was a technical report from the C standard committee. The report was incorporated almost verbatim — with an extra, previously omitted, function, IIRC — in the C11 standard as (optional but 'normative') Annex K. There's also TR 24731-2 for a different set of functions — without the _s suffix. It ran into resistance for a different set of reasons.

Also, there is a proposal before the C Standard Committee that the functions be removed from the next revision of the standard:

• N1967 Field Experience with Annex K — Bounds Checking Interfaces

That paper is a straight-forward and compelling read of the reasons why the TR-24731 (*_s()) functions have not been widely implemented.

Key reasons include:

• The problem is only spotted once, then fixed, and then the *_s() function is unnecessary.
• This makes it very hard to test the *_s() functions, or the code which uses them.
• It isn't easy to integrate the new functions into old code (which is where there'd be most benefit).
• The functions inherently slow down software with extensive but redundant checking.

See the paper for more details. The paper ends with the section:

Suggested Technical Corrigendum

Despite more than a decade since the original proposal and nearly ten years since the ratification of ISO/IEC TR 24731-1:2007, and almost five years since the introduction of the Bounds checking interfaces into the C standard, no viable conforming implementations has emerged. The APIs continue to be controversial and requests for implementation continue to be rejected by implementers.

The design of the Bounds checking interfaces, though well-intentioned, suffers from far too many problems to correct. Using the APIs has been seen to lead to worse quality, less secure software than relying on established approaches or modern technologies. More effective and less intrusive approaches have become commonplace and are often preferred by users and security experts alike.

Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.