| Date: | June 2, 2005 / year-entry #137 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050602-33/?p=35463 |
| Comments: | 45 |
| Summary: | In response to the news that strncpy is so dangerous, at least one person has called for Visual Studio to revoke support for such a dangerous function, considering the continued support for the function grounds for holding the compiler manufacturer liable for any defects in programs compiled with that compiler. Well, for one thing, while... |
In response to the news that Well, for one thing, while it's true that For another thing, just because something is dangerous doesn't mean it shouldn't be supported. Pointers and casts are dangerous, but I don't see them disappearing from C or C++ any time soon. Third, support for |
Comments (45)
Comments are closed. |
I read that guys blog about how Visual Studio should stop supporting the function.
He’s just a negative loser from what i can make of most of his posts.
Why is it that more and more people what to replace Talent with Liability on someone else?
(I’m refering to the statement he made saying that MS is liable for any and all problems caused by strncpy).
Rather than remove strncpy, could this (and other frequently abused functions) be added as a new class of warnings?
I think many of these unsafe string functions actually are deprecated if you use the strsafe.h header that comes with the Windows Platform SDK.
How would you like it if you were forced to download a so-called browser, and found it couldn’t render a large class of valid HTML, let alone CSS?
"I think many of these unsafe string functions actually are deprecated if you use the strsafe.h header that comes with the Windows Platform SDK."
They are – which leads to a whole pile of other things in SDK header files falling over.
ATL seems particularly vulnerable.
I do wish the SDK header files were cleaner.
What’s really dangerous is developers who are ignorant of the APIs they use. Other than educating them (preferred), I don’t see much that can be done about that. The new safer CRT stuff and strsafe.h can all be used to create overflows if you mess up your math (shameless plug – search on SafeInt and read up on that).
I don’t like strncpy semantics, but there are other functions I can use, and there is std::basic_string, so IMNSHO, get over it.
There’s also:
#define strncpy DoNotUseStrncpyEver
geez…
Raymond,
Looks like developers commenting here are not ready with the implications of servicing.
How about adding strlcpy / strlcat? Based on code I read, they do what many people think strncpy / strncat do.
Personally, I think Whidbey should pull support for any arrays of char or wchar, outside of the std::basic_string. (Backcompat be damned!)
Arrays are evil. strncpy is just a symptom of the underlying disease. :-)
VS .Net 2005 mark a lot of functions (such as sprintf, wcscpy – and I think strncpy) as deprecated, and output warnings to that effect. Now if you treat warnings as errors (I think there’s a switch for that) wouldn’t that be the same as removing the function ?
This sort of thinking is the ultimate example of the nanny-state point of view.
My car, if operated properly, is a safe, cheap and reliable way to travel. If operated by someone crazy, stupid, drunk or ignorant enough, it becomes a tool of death & destruction.
The idea of banning functions or assigning legal liability to compiler vendors for whatever the security nazi’s deem "unsafe" is fundamentally flawed and creates a dreadful precedent.
Yeah, strncpy is dangerous. So is a Hole Hawg:
http://www.totalgrandrental.com/images/Hole%20Hawg.jpg
But it’s fast and it works. In particular, it doesn’t have to check EVERY SINGLE BYTE to see if it’s a null.
Well, actually it does, because it has to zero-pad the dest if the source is shorter.
Yup, you’re right – I guess I was thinking of memcpy.
Munge, who forces you to download and install Internet Explorer updates?
You dont *need* to install the patches if you dont want to.
Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and PERL have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language.
To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I’ve never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.
C’s biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C requires a programmer to laboriously work with chunks of memory.
Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.
Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or – even better – Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.
So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and Visual Basic.
Having programmed in both for many years, I believe that VB has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java’s source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. Microsoft’s "shared source" under which Visual Basic is released definately seems to be the most fair and reasonable of all the licenses in existance, with none of the harsh restrictions of the BSD license. It also lacks the GPLs requirement that anything coded with its tools becomes property of the
FSF.
I hope to see a switch from C to VB very soon. I’ve already spoken with various luminaries in the C coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Marc Lucovsky, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in Visual
Basic. Jim Gray plans to support this, and hopes that the great cheese himself, Dave Cutler, won’t object to renaming Linux to VB/Linux. Although not a C coder himself, I’m told that Microsoft’s very own Robert Scooby will support this on his web site. Finally,
Dennis Ritchie is excited about the switch!
Thank you for your time. Happy coding.
Um, wow.
Note: the above, long diatribe about higher level languages is parody. (And not written by me).
And damn good parody it is too.
My take on this whole debate:
Enough of my C++ code is breaking with VS 2005 anyway. Don’t break more than you have to; I don’t have time right now to get rid of every last strcpy/strncpy call in my code – and I know that it causes problems.
I do, however, want the benefits of profiler-guided optimization, the more immediate UI for debugger support, the better minidump support, etc etc, so I want to move to VS 2005 – and the sooner the better.
Don’t make my life more difficult because there’s a "right way" of doing things. Get it through your thick skulls that the right way often falls foul of schedule and time pressure. A lot of us have to support 10 year old code – and yes, we’d love to rewrite it all, but frankly that’s not going to happen in 9 out of 10 cases. If you’re willing to work for me for free to rid my code of all its strcpy usage so that this feature can go through, but if you’re just going to bitch that it should be removed because it’s "dangerous", then not only are you singing to the choir, but you obviously have your priorities screwed on wrong.
I think we should ban integers. All those integer overflow bugs would go away instantly.
If you abolish strncpy, then the terrorists have won.
"…considering the continued support for the function grounds for holding the compiler manufacturer liable for any defects in programs compiled with that compiler."
Great news. Finally I can release a buggy library and blame the compiler!
To me the best solution is issue a level 1 warning or even an error which may be disabled toggling the right switch.
gcc issues a warning for gets() and I think this is a fine approach.
Sorry – should have said:
If you’re willing to work for me for free to rid my code of all its strcpy usage so that this feature can go through, ***then go right ahead.***
While AC’s comments are obviously a joke and quite humourous as well, I’ve often thought that C as a language is too complicated and low level for many types of applications.
Sure, if you are writing a device driver or a system kernel or similar then you require the extra speed and power of a language like C.
If however, you are writing a vanilla desktop application, why write in a language like C where you are open to buffer overruns, memory leaks etc.? This is where languages like Java and C# excel (and to a much lesser extent VB). Now in the early days Java was way too clunky and AWT was horrible (with Swing being a small improvement) but nowadays for the majority of applications that users use and the computers they use them on languages like C# and Java are a great, safe option that avoid crazy low-level functions like this.
This post made me so angry I just had to respond immediately.
>> Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and PERL have been.
All those languages are still in everyday use.
>> While I’ve never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.
C itself hasn’t been here for 15 years, let alone VB.
>> Jim Gray plans to support this
Mr Gray only really programs in SQL, which is a language with which you can create database programs.
>> Dave Cutler, won’t object to renaming Linux to VB/Linux.
The name Linux is patented by the Free Software Foundation, and they would not allow this even if it weren’t such an absurd proposition.
>> Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or – even better – Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.
Java.net is fast, but that is because it gives every program a virtual machine to play with. C would be just as fast if it had a quantum computer too.
>> By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.
The big advantage of pointers is they gives you far greater control of how to use your memory. In particular, they let you do something called Object Orientated Programming. So for instance, if you wanted to build a database of customers for your local hospital, you could assign a object to each person. (Of course, care has to be taken not to typecast. And this method is only applicable to males, because women are not objects).
>> So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and Visual Basic.
But C has the added bonus of giving you free entry to any library whose name ends with h, although unfortunately there aren’t many places like this in the US.
Trash like this really makes my blood boil!
I will admit I thought it was real. However, I have seen stuff like that posted before in all seriousness.
Or to put it another way, if you make strncpy illegal only the criminals will use strncpy.
"To me the best solution is issue a level 1 warning or even an error which may be disabled toggling the right switch."
Good, then you’re gonna like Microsoft’s solution(*)
You get a level 1 warning, which you may treat as an error if you want to.
Pragma ignore the deprecation warning and you won’t be disturbed by this :)
* This is based on beta information(download the public VC++ Express and see for yourself). May change when released (hope not).
Okay, then, just remove pointer arithmetic and we won’t eat the fluffy bunny for dinner.
I must say the quality of the trolling here is quite amusing. The one by Mattel had me rolling my eyes before it got so ridiculous.
It’s weird, why don’t people realize that you’re totally allowed to write your own string functions in C. You can even write a strncpy function that always null terminates the string, you just have to give it a different name.
Sunday, June 05, 2005 2:38 PM by Matt
> You can even write a strncpy function that
> always null terminates the string, you just
> have to give it a different name.
No you don’t. If you use a freestanding implementation, you can write any kind of function you want and you can call it strncpy.
Loser. I hate this "I am stupid but its somebody else fault" attitude. Reminds me of all the famous american court decissions.
You mean silly court cases like the coffee spill case and McDonalds? I would read about the case a little more before you go off thinking it was a silly case. McDonalds could have gotten off with just paying the woman $20,000 to cover her medical expenses from the third degree burns causes by the near boiling water.
But no, they got silly.
Wednesday, June 08, 2005 7:25 AM by Matt
> Sunday, June 05, 2005 7:58 PM by Norman Diamond
>> Sunday, June 05, 2005 2:38 PM by Matt
>>>
>>> You can even write a strncpy function that
>>> always null terminates the string, you just
>>> have to give it a different name.
>>
>> No you don’t. If you use a freestanding
>> implementation, you can write any kind of
>> function you want and you can call it
>> strncpy.
>
> Yeah, but only an idiot would do that.
Of course. I was replying to the "you just have to give it a different name" part of your posting, which is a completely separate issue from common sense ^_^
Cleverness is useful, and it might be handy for someone to write a new strncpy function (like if they were working code that was isolated from /everything/), but cleverness for cleverness’ sake is a stupidity and I feel it needs to be opposed. There’s way too much cleverness in the world as far as I’m concerned. :-)
Am I the only one who actualy have read the "manual" page for strncpy and take it’s behaviour into account when using it?
I like to have all warnings turned on when compiling (well, when using 3rd party stupid libs, I lower the setting), but if it’s true MSVC will have a warning for strncpy, that one seems pretty silly.