Al said:
Al said:
[...]
Even GCC decided not to add it
Did you follow the GNU discussion back then? IIRC, the main argument
against it, was that few C programmers, demanded these functions and
that rolling your own would be easy.
Only sporadically, since I didn't have any strong feelings either way.
I remember claims that there was no evidence that they made things
safer, despite their long history in BSD,
IMO, security wise, OpenBSD track record is rather good. OpenBSD homepage:
"Only two remote holes in the default install, in more than 10 years!"
As a security professional, I prefer to talk about higher assurance
level, rather than "safer". Safety and security, isn't the same thing.
Assurance level increase, when performing code audit, using more robust
& simpler API etc.
and that it's better for
programmers to be aware of how long their strings are, rather than
having to check whether data was truncated. I certainly agree with the
last, since programmers who can't properly handle strings are probably
among those who never check return values
I find that argument was rather silly.
In particular library developers, should know how to write
post-conditions. My own strlcpy() and strlcat() implementation from 7
years ago, had assert() in place, to detect truncation.
I can't remember, ever being hit by a truncation bug, after the module
test phase.
A little while ago, I was asked to enhance a Windows program I wrote a
few years ago. An upgrade to the latest Visual Studio was required, as
well. One of our regular Windows programmers was happy to tell me how
to turn off the warnings about not using the *_s functions <G>.
A simple #pragma warning (disable: NNN) should do.
With the latest VC++, I couldn't figure how to create a simple console C
project, without those C++ files being generated. :-(
So, I still use VC++ 6, when possible.. less bloated and no *_s warnings.