Thread: Annoying compilers

I find it annoying that no-one uses the safer versions and sticks to old, messy crap versions.

Well, those "old, messy crap versions" happen to be part of an international standard.

Those shiny, new, safe versions are ... well, MS added them in 2005. Nobody else supports them. Nobody else will, anytime soon. Probably. No legacy code uses them, obviously. They're not attractive from a code maintenance viewpoint, from a "that's what I've always used" viewpoint, from a portability viewpoint.

That said, I do use them in a recent definitely-Windows-only project. Mostly because I don't want to go to the trouble of shutting up the warnings. For many of them, I don't see how they are any safer. What the hell is the difference between these?

Code:

int fprintf(FILE* f, const char* fmt, ...);
int fprintf_s(FILE* f, const char* fmt, ...);

Yeah, I know.

These functions differ from the non-secure versions in that the format string itself is also validated. If there are any unknown or badly formed formatting specifiers, these functions generate the invalid parameter exception.

Slow extra validation in the _s version. But not that slow. (Or I don't see why it would be.) I really don't think it's justified to create an extra function for this.

And yet, MS still hasn't managed to implement static parameter validation for the printf family (for compile-time-known format strings, obviously), something that GCC has had forever. Great fun! I can pass a CString to a formatter and never know until it crashes. But only if it wasn't the last parameter, because otherwise it just happens to work, since the pointer is a CString's first member.


Me, ranting?

Originally Posted by CornedBee

Well, those "old, messy crap versions" happen to be part of an international standard.

Those shiny, new, safe versions are ... well, MS added them in 2005. Nobody else supports them. Nobody else will, anytime soon. Probably. No legacy code uses them, obviously. They're not attractive from a code maintenance viewpoint, from a "that's what I've always used" viewpoint, from a portability viewpoint.

I would dearly love them to be part of the new standard. Clearly, a good thing would be for the standard to add them and deprecate the old functions, meaning that in new projects, the new functions should be used.
But then again, perhaps they won't because of the extra overhead. C was not really meant for modern applications. It is nowadays better for certain embedded platforms where such extra checks might be too costly or not necessary.

And yet, MS still hasn't managed to implement static parameter validation for the printf family (for compile-time-known format strings, obviously), something that GCC has had forever. Great fun! I can pass a CString to a formatter and never know until it crashes. But only if it wasn't the last parameter, because otherwise it just happens to work, since the pointer is a CString's first member.

Anything that helps point out bugs and errors in the code is welcome by me. I would love such support in Visual C++. Get cracking, Microsoft!

I think programmers see these safe versions as "hey, that's the job of a debug mode". For example, the invalid format string checking of printf_s. At the same time, they're warning that you should never ever use user input as the format string. (Very good advice, that.)
So the only source of format strings is the people involved in developing the application: programmers and translators (assuming you're inexperienced enough to think that printf is an even remotely adequate localization tool). But if that is so, then all invalid format strings should be catchable before the application leaves the developers, i.e. in debug mode.
Why, then, would I pay for the extra validation in release mode?

Others, such as strtok_s, are always useful. But then, strtok_s is actually in the POSIX standard - under the name strtok_r (for reentrant).

Catching buffer overflows is very, very useful too. And it's part of strcpy_s, strcat_s, among others.
And not just security applications, but any desktop (ie PC/Mac) application.

And it's part of strcpy_s, strcat_s, among others.

Only if you actually get the buffer size right. That's still a very real issue.

Originally Posted by Elysia

And not just security applications, but any desktop (ie PC/Mac) application.

Well, of course it is, from a usability perspective. But in 99% of cases, a buffer overflow will achieve nothing more than a weird crash (and thus a loss of data, if you hadn't saved your file two seconds ago). There are cases where buffer overflows allow privilege hoisting. And of course, if the application is listening to arbitrary network traffic, then it would allow an outsider to send a packet that can allow the application to become the hose of all sorts of nasty stuff.

But if the application that I'm using is overflowing because I wrote a too long line in my text file, all that is going to happen is a crash. Which is not great. But it's not a security issue in any way shape or form - unless someone ELSE can convince me that I should open THEIR FILE with some weird data in it (that allows the app to perform some operations I didn't really want it to perform).

--
Mats

Originally Posted by CornedBee

And yet, MS still hasn't managed to implement static parameter validation for the printf family (for compile-time-known format strings, obviously)

To be fair it seems to be only %s arguments that aren't validated, although that's little consolation considering %s is probably the most widely used.

Code:

int val = 0;
char* str = 0;
printf("%p", val); // C4313: 'printf'  : '%p' in format string conflicts with argument 1 of type 'int'
sprintf(NULL, "%d", str); // C4313: 'sprintf'  : '%d' in format string conflicts with argument 1 of type 'char *'
fprintf(NULL, "%u", str); // C4313: 'fprintf'  : '%u' in format string conflicts with argument 1 of type 'char *'
printf("%s\n", val); // nothing

Looks like I missed something, compiling in VS2008 pro with /analyze gives

warning C6066: Non-pointer passed as parameter '2' when pointer is required in call to 'printf'
warning C6273: Non-integer passed as parameter '3' when integer is required in call to 'sprintf': if a pointer value is being passed, %p should be used
warning C6309: Argument '1' is null: this does not adhere to function specification of 'sprintf'
warning C6273: Non-integer passed as parameter '3' when integer is required in call to 'fprintf': if a pointer value is being passed, %p should be used
warning C6309: Argument '1' is null: this does not adhere to function specification of 'fprintf'
warning C6067: Parameter '2' in call to 'printf' must be the address of the string
warning C6387: 'argument 1' might be '0': this does not adhere to the specification for the function 'sprintf': Lines: 7, 8, 9, 10
warning C6387: 'argument 1' might be '0': this does not adhere to the specification for the function 'fprintf': Lines: 7, 8, 9, 10, 11

Neither 2003 or 2005 seem to use more than one thread when compiling which brings my quad-core processor at work to it's knees and maxes out 1 core all the time. Not sure why they could not fire off multiple threads for the actual compile process.

/MP was introduced (though undocumented) in VS2005

Well, we use 2005 at work, and I don't get any such warnings. Also, I believe the analyze option is not available in our edition.

Originally Posted by CornedBee

Only if you actually get the buffer size right. That's still a very real issue.

Buffer size is (usually) easy to get right, however, if that's any consolidation. I think it's better than nothing. But they could be better, yes.

As for /analyze:

Originally Posted by MSDN

/analyze is only available in Enterprise (team development) versions for x86 compilers.

That seems stupid. I only have access to Professional versions...

> Catching buffer overflows is very, very useful too. And it's part of strcpy_s, strcat_s, among others.
That's where our friend "Mr. Virtual Machine" comes in. But I forgot you don't like them

> Slow extra validation in the _s version. But not that slow. (Or I don't see why it would be.)
Perhaps a benchmark is in order?

Originally Posted by zacs7

> Catching buffer overflows is very, very useful too. And it's part of strcpy_s, strcat_s, among others.
That's where our friend "Mr. Virtual Machine" comes in. But I forgot you don't like them

Eh, but I'd rather like functions that tells me of overflows instead of me having to test for them.
And virtual machines are slow -_-