_S for Sneaky

Ensuring that one’s costumer base remains loyal, also known as lock-in, is an important part of many software and hardware manufacturers’ business plan. Recently, I came across an especially displeasing example of sneaky and subtle customer lock-in strategy from our friends at Microsoft.

Sneaky Cat is Sneaky

Sneaky Cat is Sneaky

If you’re (at least trying to) writing portable code, you certainly noticed that Visual Studio complains a lot about certain functions being deprecated. Standard functions like strcmp, memcpy, and a few others. Why would a compiler complain about those if they’re still very much part of the current C standard?

Well, the code safety argument have been brought up. Making the inherently insecure C standard library a bit more secure seems like a good idea. For example, it may be good to replace the basic memcpy( void * dest, void * src, size_t move_size) with the more secure errno_t memcpy( void * dest, size_t dest_size, const void * src, size_t move_size) that returns an error whenever move_size is larger than dest_size or if either src or dest is NULL—but not if the buffers overlap, which results in undefined behavior, which is still very bad.

Well, I can’t argue against the fact that we need a better, more secure C standard library as it appears to be a more or less disparate collection of legacy vendor-specific libraries somehow elevated to the grace of standard. So what beef do I have with those practices? A message like this:

warning C4996: 'memcpy': This function or variable may be unsafe.
Consider using memcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.

As if you, the programmer, were at fault. That’s a sneaky way of forcing programmers to write non-portable code by using Microsoft-specific extensions, and thus lock the application to the Windows platform in a very perverse way. Just by the very way the warning is presented, the programmer feels like he’s writing bad code, despite his using the standard, portable, universally available function. The programmer is forced to feel that he should have better practices and prefer Microsoft’s “safer” functions—enhanced safety which remains entirely to be seen given the nature of the C language—but in fact, he’s just shackling himself, and his code, a bit more to the Windows platform!

Sneaky, sneaky bastards.

* *

You can use the compiler option /wd4996 or use #undef _CRT_SECURE_DEPRECATE_MEMORY in the source code before including <memory.h> (or <string.h>) to get the compiler to behave as a normal C compiler and stop complaining about “deprecated” functions.

* *

The root problem is, of course, that C and C++ lack the notion of array as it exists in other programming languages. The weak typing of these languages makes it particularly simple to loose a part of the type of an array, reducing int t[8][8] to a mere int t[][8], where the number of items is incompletely specified. Since this information is lost—and quite so by design—it is impossible to have efficient and complete compiler-generated bound checking. In C++, however, one can use array replacement classes (such as std::vector<T>) and built in bound checking, but the classes must still offer most of the semantics of a regular array to be usable.

3 Responses to _S for Sneaky

  1. JMD says:

    You can easiy rewrite your own set of _s functions if you need to port code to UNIX or another OS.
    Using _s functions is still a good strategy.

    • Steven Pigeon says:

      Safer functions are always better than less safe functions. The C Std Lib string functions are retarded, everybody will agree. My point was that the warning deprecates the normal, standard functions. There’s a difference between “function X is deemed unsafe, consider safer equivalent X_s” and “function X is deprecated, use vendor-specific X_s”.

      • JMD says:

        I agree that they should have said “consider vendor specific function” instead of “this standard function is deprecated”, but I still say that it was a good idea. If you do not want the warnings, you can #define _CRT_SECURE_NO_DEPRECATE, if you want you can automatically change to the safe functions without changing your code by #defining _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES and if you want you can also change the functions one by one by adding _s. I don’t see how they could have done a better job! I’m not working for microsoft in any way by the way!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: