_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

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.