strcat_s problems

This is a discussion on strcat_s problems within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Aisthesis interesting the discussion on deprecation and IDEs. to Salem: So, if the number is supposed to ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Quote Originally Posted by Aisthesis View Post
    interesting the discussion on deprecation and IDEs.

    to Salem: So, if the number is supposed to be the SIZE of the destination string buffer, and my destination string buffer is FullName[46], does that mean that I need to use 46 every time? like as first command

    strcpy_s(FullName, 46, Last);
    Yes, that or better yet, sizeof(FullName).

    I also agree that some functions cannot simply be wrapped in macros. They can be a little more problematic, and perhaps should be avoided by newbies, but strcat_s and strcpy_s are very, very easy using macros:

    Code:
    #ifndef _MSC_VER
    #define strcpy_s(dst, dst_length, src) strcpy(dst, src)
    #endif
    And one should also remember that these so called "secure" functions may not be secure (misleading name), but they DO protect against programmer mistakes, such as out-of-bounds writing which is helpful to any programmer to aid in debugging and especially to newbies who can very easily make such mistakes.

    So when compiling in MSVC, we get added debugging functionality (good), and if we compile in another compiler, it will still compile due to the macro wrapper, so it essentially becomes ISO standard code (good). So no harm comes at all.
    This is what I base my suggestion at.
    I might or might not suggest the same for other "safe" functions. And I do agree that there's a lot of broken documentation and a poor word of saying they aren't recommended.
    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.

  2. #17
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    So when compiling in MSVC, we get added debugging functionality (good), and if we compile in another compiler, it will still compile due to the macro wrapper, so it essentially becomes ISO standard code (good). So no harm comes at all.
    But the problem is, if the programmer relies on the buffer size checking function, the code, when compiled by another compiler, won't be secure (since the dst_length parametre is macro'ed out).

    So the portable way would be to make sure the buffer size is big enough manually BEFORE calling strcpy(_s). At that point... might as well just call the standard function.

  3. #18
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,762
    > Yes, that or better yet, sizeof(FullName).
    Or not.
    The OP was allocating memory, so sizeof isn't going to do what you want.

    > but they DO protect against programmer mistakes,
    But only if you're smart enough to RTFM and understand what it's telling you.
    As the OP demonstrated in #6, if you LIE about the size of the buffer you're using, then you're no better off than you were before.

    Except that you might get into a mind-set that so long as it doesn't actually crash, then your use of _s functions somehow makes it all nice and safe.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #19
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    Quote Originally Posted by cyberfish View Post
    But the problem is, if the programmer relies on the buffer size checking function, the code, when compiled by another compiler, won't be secure (since the dst_length parametre is macro'ed out).

    So the portable way would be to make sure the buffer size is big enough manually BEFORE calling strcpy(_s). At that point... might as well just call the standard function.
    As I pointed out, it's not necessarily more secure at all. If you want to call an assert/crash more secure, then sure. Otherwise it's merely a debugging tool and not a security measure (then it would simply fail and return an error).
    So for your second argument that becomes invalid too - because the *_s functions is a tool to help you catch mistakes where you didn't make your buffer big enough.
    You really should make the buffers big enough in the first place, the "secure" functions won't fix that, but it will tell you if you screwed up.

    Quote Originally Posted by Salem View Post
    > Yes, that or better yet, sizeof(FullName).
    Or not.
    The OP was allocating memory, so sizeof isn't going to do what you want.
    True, when formulating that reply, I was looking at the...
    FullName[46]
    ...bit.
    So if using a local buffer, ie char FullName[46], then sizeof will be right. If dynamically allocated via new, then it is not correct.

    > but they DO protect against programmer mistakes,
    But only if you're smart enough to RTFM and understand what it's telling you.
    As the OP demonstrated in #6, if you LIE about the size of the buffer you're using, then you're no better off than you were before.
    Everything needs the knowledge to use it. Compiler warnings and errors and no different.
    When you see a warning, you look it up and fix it. Normally anyway.
    Though a newbie may not do this, so I do not see how it differs from that of compiler warning outputs.

    Except that you might get into a mind-set that so long as it doesn't actually crash, then your use of _s functions somehow makes it all nice and safe.
    Ah yes, pitfalls. There are always those, and I don't think this is an exception.
    And I don't think we should consider something bad because of a few pitfalls.
    As with everything, it helps to understand the function and what it does and what it does not do.

    *shrugs*
    What else can I say?
    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.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. No clue how to make a code to solve problems!
    By ctnzn in forum C Programming
    Replies: 8
    Last Post: 10-16-2008, 03:59 AM
  2. C Pointers Problems
    By mhelal in forum C Programming
    Replies: 8
    Last Post: 01-10-2007, 06:35 AM
  3. String Manipulation problems -_-
    By Astra in forum C Programming
    Replies: 5
    Last Post: 12-13-2006, 05:48 PM
  4. Rendering problems (DirectX?)
    By OnionKnight in forum Tech Board
    Replies: 0
    Last Post: 08-17-2006, 01:17 PM
  5. DJGPP problems
    By stormswift in forum C Programming
    Replies: 2
    Last Post: 02-26-2002, 04:35 PM

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