Annoying compilers

This is a discussion on Annoying compilers within the A Brief History of Cprogramming.com forums, part of the Community Boards category; I find it annoying that no-one uses the safer versions and sticks to old, messy crap versions. Well, those "old, ...

  1. #16
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #17
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,918
    Quote Originally Posted by CornedBee View Post
    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!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #18
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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).
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #19
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I could see utilizing the 'safe' versions in security applications but I don't see the benefit in using them in much else. They are wholly confusing and the naming convention is just awful.

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,918
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #22
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    I can understand some of the idea of the safe functions but the fact is..they are only as safe as the programmer using them...which brings me to the idea that how are they any different than the unsafe ones which rely on the same fact?

    As of right now I have no use for them since my current job is on embedded systems. I do not create desktop applications.

  8. #23
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #24
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >I couldn't figure the compiler error...


    as a general statement I'd say it's not fair to complain about bad compiler errors until you've tried to write you're own compiler. It's not always as easy as you think to come up with a nice user friendly explanation of what went wrong.

    In this case it's pretty bad though. A lot of IDE's warn you about these types of errors, I guess the lesson is that code compilation and code validation are inherently different tasks.

  10. #25
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    612
    Quote Originally Posted by CornedBee View Post
    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
    Last edited by adeyblue; 11-27-2008 at 05:45 PM.

  11. #26
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #27
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,918
    Quote Originally Posted by CornedBee View Post
    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:
    Quote 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...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #28
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    > 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?

  14. #29
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,918
    Quote Originally Posted by zacs7 View Post
    > 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 -_-
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #30
    Registered User
    Join Date
    Aug 2008
    Posts
    188
    does anyone know why MS chose to use strcpy_s, strcat_s instead of preprocessor?

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C++ Builder Comparison
    By ryanlcs in forum Tech Board
    Replies: 14
    Last Post: 08-20-2006, 10:56 AM
  2. Is It Possible To Install Multiple Compilers?
    By mishna_toreh in forum C Programming
    Replies: 3
    Last Post: 05-13-2005, 08:32 AM
  3. Compilers for Windows
    By LegendsEnd in forum Windows Programming
    Replies: 2
    Last Post: 03-26-2004, 08:03 AM
  4. small compilers?
    By Korn1699 in forum C++ Programming
    Replies: 2
    Last Post: 06-22-2003, 06:58 PM
  5. Compilers, Compilers, Compilers
    By Stan100 in forum C++ Programming
    Replies: 11
    Last Post: 11-08-2002, 04:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21