.dll Question VS2009 "warning"

[jtiberius]

Hi there,

can someone tell me what this warning is about?

c:\orbiter dllmaking\orbitersdk\samples\ipc2\ipc2\ipc2.cpp(311) : warning C4996: '_strnicmp': The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _strnicmp.

Thanks
jtiberius

 

[Artlav]

Is it "_strnicmp" in the code? If it is, then it's weird.

 

[jtiberius]

yep, it´s in the sample HST code.
That´s pretty hard for a greenhorn like me, now i have some very strange
animation behavior. anyway "compile and test"

 

[Urwumpe]

The warning is usually coming when you use "unsecure" stdio functions, which have a tendency for buffer overflows with the intended behavior, if you don't do the checks yourself before calling them.

But this warning is still strange...I don't use VC2009 yet though.

 

[dbeachy1]

Urwumpe is correct. That warning is present in VS2003 and newer compilers to remind developers that older (now-deprecated) versions of CRT string functions are vulnerable to buffer-overflow attacks. If your C++ source file includes OrbiterAPI.h (before #include <windows.h>, however), it should disable those warnings for you. Here is the relevant section in OrbiterAPI.h:

#if defined(_MSC_VER) && (_MSC_VER >= 1300 ) // Microsoft Visual Studio Version 2003 and higher
#define _CRT_SECURE_NO_DEPRECATE 
#include <fstream>
#else  // older MSVC++ versions
#include <fstream.h>
#endif

If your C++ source file generating the warning does not include OrbiteAPI.h you can #define _CRT_SECURE_NO_DEPRECATE manually, but be sure to define it before '#include <windows.h>'. If you are including <windows.h> manually, you will either have to include OrbiterAPI.h first or #define _CRT_SECURE_NO_DEPRECATE yourself before you #include <windows.h>.

EDIT:
The reason the warning message mentions '_strnicmp' is because 'strnicmp' is a #define that may evaluate to either the 8-bit version or 16-bit (Unicode) version of the function. _strnicmp is the 8-bit character version. More information here: http://msdn.microsoft.com/en-us/library/chd90w8e%28VS.80%29.aspx

 

[Wraith]

Actually, the functions aren't deprecated. Feel free to use them as you had learned. Good news: the world didn't turn upside down, as you may have thought.

There's been an outcry after VC2005 was out and that crap started to pour on the heads of unsuspecting coders. It's perfectly legal in C and C++ to use functions strlen(), strcmp(), sprintf(), fgets() and the likes, and also std::copy(). Microsoft had no "right" to declare them deprecated, because neither ISO 9989 (C) nor ISO 14482 (C++) do declare them as such.

According to ISO 14882, "deprecated" means "avoid, future versions of the standard may remove this".

There are literally millions of programs written with the use of "unsecure" CRT functions, you cannot simply dike out a feature without breaking those programs.

The very best thing you could do to stop that kind of crap is to locate crtdefs.h in vc/include directory and stamp those #define xxx_NO_DEPRECATE right on top, to turn the warnings off once and for all.

A couple of links to consider: 1 2.

Edit: Also the ...printf functions are already broken since VC 2005. Ever heard of a wonderful '%n' specifier? (Not that widespread, but good to have around in some cases.) Well, MS decided that it's too dangerous for you to use it, and simply disabled it. And so printf() doesn't behave as required by standards. Wait, you didn't actually know that, did you? Happy late night debugging then! Oh, and in a sort of good will and infinite kindness they added a safety switch (but it's hard to find). Like in a gun, you know. A perfect attitude!

 

[Urwumpe]

Wraith: I have to disagree completely. Not that I like the warnings. But your medicine is pretty much the wrong direction, since you just go on with the bigger problem, instead of solving the smaller.

You can either use the updated functions (which will likely become standard in this form or similar), or disable the warning by just setting a simple compiler command line argument. Both is not that terrible and at least keeps on keeping you aware of the situation - you can ignore the yellow warning light by setting the compiler flag or fix the circumstance and use the better functions.

also, these functions have been defined in 1970, long before the unsecure interface had effect because of unaware users of these functions in the internet - before, you usually had enough time and enough chances to fix the damage before it became severe. Getting new standards into C or C++ is much harder and takes longer than just leveling a mountain range with a spoon.

 

[Wraith]

Well, that's the problem.

First of all, the so-called 'safe' functions are even worse, than 'unsafe'. That's because despite what Microsoft call them, they are not safe. They add no security, but instead give a false sense of security.

Second, now that we have moved away from seventies, there are plenty of other languages that offer substantially more functionality and security over what we have with C and its CRT. They all trade performance for security, and so those who want buffer overflow security should choose languages other than C.

Third, the buffer overflow security isn't always required. And writing Orbiter plugins is exactly the case. You see, no one's going to attack Orbiter users via, say, improperly written scenario file that has lines greater than 2048 characters. It's like wearing aqualung when you go to the bathroom. Most games forego this 'security' and use good old sprintf().

 

[Urwumpe]

First of all, the so-called 'safe' functions are even worse, than 'unsafe'. That's because despite what Microsoft call them, they are not safe. They add no security, but instead give a false sense of security.

Can you elaborate rationally on that? The links you have given are pretty much the usual "oh my god microsoft did it again" whining, that agrees actually that the new functions are safer indeed, but reduces the magical entity called "performance".

If you ever don't like a safe and robust solution and run out of rational arguments, you say it has a bad performance impact. That is likely true, because without error checking and validation of the parameters, you are in deed faster, but in 99.999% of the cases, you will need to use special timer hardware for measuring the performance impact, because the multimedia high-speed timers on a PC are not fast enough.

Very often, you spend many more workhours on getting performance optimized, so that the runtime saved on all copies of the application for the whole life cycle of the product is less than the work put into it...

And for optimized copying of chars, you don't use the strncpy or strcpy stuff, but directly use an inline assembler snippet for copying a buffer of machine words, and maybe terminate the copy with a terminator symbol if needed.

 

[movieman]

Wraith: I have to disagree completely. Not that I like the warnings. But your medicine is pretty much the wrong direction, since you just go on with the bigger problem, instead of solving the smaller.

The problem is that Microsoft have, as they so often do, taken a good idea and implemented it really badly: people shouldn't be using old insecure functions because they're a huge source of security holes, but by spewing out millions of warnings they merely encourage everyone to turn those warnings off rather than do something about it.

 

[Wraith]

Can you elaborate rationally on that? The links you have given are pretty much the usual "oh my god microsoft did it again" whining, that agrees actually that the new functions are safer indeed, but reduces the magical entity called "performance".

If you read the second article, that will give you an example. The main source of all the problems, of course, is in the essence of C: there are no strings in C.

If you ever don't like a safe and robust solution and run out of rational arguments, you say it has a bad performance impact. That is likely true, because without error checking and validation of the parameters, you are in deed faster, but in 99.999% of the cases, you will need to use special timer hardware for measuring the performance impact, because the multimedia high-speed timers on a PC are not fast enough.

Very often, you spend many more workhours on getting performance optimized, so that the runtime saved on all copies of the application for the whole life cycle of the product is less than the work put into it...

But that actually doesn't matter.

You can split all situations into two simple categories:
1. You care about performance.
2. You don't care about performance.

In the first case, the runtime validation has to go. When writing performance-critical code, a programmer "compiles" the code in his mind just as he types in the statements. The programmer learns what to expect from the compiler, but various task-irrelevant pieces of code greatly obscure the projected result.

In the second case, C shouldn't be the language of choice. It will be a waste of time.

Good professional tools are those that act in close accordance to standards and specifications, and that can be relied upon, not those that have shiny fool-proof switches.

 

[Urwumpe]

The problem is that Microsoft have, as they so often do, taken a good idea and implemented it really badly: people shouldn't be using old insecure functions because they're a huge source of security holes, but by spewing out millions of warnings they merely encourage everyone to turn those warnings off rather than do something about it.

Yeah, the microsoft compilers are famous for producing warnings for any nonsense and keeping you from seeing the real problems.

Like

std::map<std::string, std::string> foo;

resulting in a warning because the symbol name became too long and had to be truncated.

But still turning warnings sweepingly off is not professional.

 

[Hielor]

In the first case, the runtime validation has to go. When writing performance-critical code, a programmer "compiles" the code in his mind just as he types in the statements. The programmer learns what to expect from the compiler, but various task-irrelevant pieces of code greatly obscure the projected result.

With modern compilers and high-level languages, this is no longer really the case.

You're also failing to consider what is probably a more common medium between high performance and high security: secure but also performant. This is what the secure string functions are there for: to give you the performance advantages of C/C++ while also preventing your software from being trivially compromised.

If you're making a piece of software where it doesn't matter, go ahead and turn off the warnings. If you're making a piece of software where it does matter, pay attention to them. It's that simple.

 

[Wraith]

With modern compilers and high-level languages, this is no longer really the case.

Quite the contrary: it's just option 2 is preferred in 99.99% of all the cases.

You're also failing to consider what is probably a more common medium between high performance and high security: secure but also performant. This is what the secure string functions are there for: to give you the performance advantages of C/C++ while also preventing your software from being trivially compromised.

There really can be no 'golden middle' for security vs performance. A software with a subtle bug that allows remote code execution is just as bad as software that has 100 obvious bugs. The functions in question *aren't* secure as they are claimed to be. They cannot be made secure, no matter how hard you try, unless you change the language.

Oh, and C++ strings are somewhat better and much more buffer-overflow secure (foolproof that is). You also get a performance overhead, as a bonus .

If you're making a piece of software where it doesn't matter, go ahead and turn off the warnings. If you're making a piece of software where it does matter, pay attention to them. It's that simple.

Well, that's what I suggested: to just turn off the warning because a plugin writer shouldn't care about buffer overflows in orbiter *that* much.

 

[Hielor]

There really can be no 'golden middle' for security vs performance. A software with a subtle bug that allows remote code execution is just as bad as software that has 100 obvious bugs. The functions in question *aren't* secure as they are claimed to be. They cannot be made secure, no matter how hard you try, unless you change the language.

The second article you linked, in talking about all the ways that these functions are "insecure", presents several ways to use the functions incorrectly and uses that as "proof" that they're insecure.

C/C++ are not languges that protect the programmer's code from bad programming, and these secure functions aren't designed to do that either. They make it easier to write correct and secure code, but they don't remove the responsibility for the programmer to actually write correct code.

Saying that these functions are not secure by showing an incorrect usage of them is like saying that a car is not safe by driving it off a cliff.

 

[Wraith]

The second article you linked, in talking about all the ways that these functions are "insecure", presents several ways to use the functions incorrectly and uses that as "proof" that they're insecure.

C/C++ are not languges that protect the programmer's code from bad programming, and these secure functions aren't designed to do that either. They make it easier to write correct and secure code, but they don't remove the responsibility for the programmer to actually write correct code.

Well, that's the whole point! What MS claims is the functions are "secure" because they made an effort to make them fool-proof.

Let's take memcpy_s() as example. Basically, good old memcpy() is perfectly secure: it does what it's told to do: it copies the amount of bytes specified and no more *. If the program abides to the contract (ISO 9989), memcpy is guaranteed to work as expected. If the program violates the contract, the behavior is undefined. Buffer overflow is a programmer's error, a failure to validate input parameters. memcpy_s() is an attempt to make the function fool-proof in a very limited number of cases, like

void f( int* arr, int N )
{
    int local_copy[256];
    if( 0 != memcpy_s( local_copy, 256*sizeof(int), arr, N ) )
    {
       // error: buffer overflow!
    }
    // ...
}

where writing a proper bounds check manually is as simple.

Forcing to use the function in every case is a waste of effort, because there will be code like

N = input_number();
memcpy_s( dest, N, src, N );

that kinda defeats the purpose.

Oh, and the function fails miserably even to be fool-proof in those limited cases. Because you see, one can make an error with good old standard and "insecure" memcpy() in two ways: to grab more bytes than source the buffer actually has *or* to stick more bytes than the destination buffer can hold. The function checks the latter, but not the former. So, the "more secure" version should have been:

errno_t memcpy_s(
    void* dest, size_t dest_size,
    void* src, size_t src_size,
    size_t count );

Oh, wait, there's more!

If the source and destination overlap, the behavior of memcpy_s is undefined.

A check for overlapping regions and a fallback to memmove_s() would have been "more secure", but they didn't bother to.

Secure? Fool-proof?

Pointless.

----
* - Terms and restrictions apply

 

[Brycesv1]

so why dont you just write your own language? i highly doubt any software is 100% bug free. even if it in itself is bug free that will not stop users from being idiots and breaking it. give me an hour to play with ur software. ill give you errors you didnt even know existed

 

[mjessick]

I work with a huge conglomeration of various simulations from various groups that compiles with (wait for it) over 9500 warnings. About 500 of them are in our code and should be cleaned up eventually. (Our build output is over 21000 lines long).

I had to write a script to cull out all the warnings that can't be fixed (because they are in the code of other organizations) to find any new ones I might have recently put in to our version.

Please write warning free code. All that clutter makes it harder for those who come after. And a small percentage of those warnings could call attention to a real hard to find bug. Try finding the important warning in a forest of warnings sometime.

 

[agentgonzo]

I work with a huge conglomeration of various simulations from various groups that compiles with (wait for it) over 9500 warnings. About 500 of them are in our code and should be cleaned up eventually. (Our build output is over 21000 lines long).

I had to write a script to cull out all the warnings that can't be fixed (because they are in the code of other organizations) to find any new ones I might have recently put in to our version.

Please write warning free code. All that clutter makes it harder for those who come after. And a small percentage of those warnings could call attention to a real hard to find bug. Try finding the important warning in a forest of warnings sometime.

I'm with you on this one. I always right code that compiles to 0 errors and 0 warnings. It really annoys me that some of my colleagues write code and just ignore warnings as they are thing they are fine. Especially when they get warnings like

if(a = b)  // rather than if(a == b)

or

a = a; // rather than this->a = a;

Bugs like this are really easy to solve if you see the compiler warning as it's obvious, but if your code throws over 400 warnings you just won't see it.

One of my friends works at a company where they compile the code with 'werror' defined for release builds (treat warnings as errors and stop compiling). This forces people to not just ignore warnings and deal with them properly.