2

I am just using these wide character literals in my code to learn about them 

     wchar_t* wpsub = wcstok(names, names_delim);
     wpsub = wcstok(NULL, names_delim);
     wchar_t* wcopied=new wchar_t[wcslen(wname) + 1];
     strcpy(nameptr, "singh");
     wcscpy(wcopied, wname);
     wcscat(wcopied, L" Singh");

why am I getting these warning,I ignored it anyway. do we need to ignore any such warnings.

    : warning C4996: 'wcstok': This function or variable may be unsafe. Consider using wcstok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcstok'
    : warning C4996: 'wcstok': This function or variable may be unsafe. Consider using wcstok_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcstok'
    : warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'strcpy'
    : warning C4996: 'wcscpy': This function or variable may be unsafe. Consider using wcscpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcscpy'
    : warning C4996: 'wcscat': This function or variable may be unsafe. Consider using wcscat_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
    : see declaration of 'wcscat'
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
munish
  • 4,505
  • 14
  • 53
  • 83
  • 1
    What is your question? Do you mean: Is it safe to ignore these warnings in productive code? Propably not, or else the implementors of the function would not bother writing such an error message. I suggest, as the warnings state, look into the safe versions of the functions. – Constantinius May 15 '11 at 09:40
  • Yes you get my point and i get your answer.thanks – munish May 15 '11 at 09:42

3 Answers3

2

You should be using std::wstring and std::string and similar C++ Standard library functions, instead of those functions, as they are susceptible to buffer overruns and other security (not to mention application reliability) issues.

Puppy
  • 144,682
  • 38
  • 256
  • 465
2

There is another reason not to use the original strtok family function:

[...] However, within a single thread, interleaving calls to one of these functions is highly likely to produce data corruption and inaccurate results. When parsing different strings, finish parsing one string before starting to parse the next. Also, be aware of the potential for danger when calling one of these functions from within a loop where another function is called. If the other function ends up using one of these functions, an interleaved sequence of calls will result, triggering data corruption.

The reason is that strtok is not reentrant: When designed, is was believed it would be a good idea for it to use a global variable as repository for the context (how did you think strtok can remember where to continue between each function call?).

The past is the past, and we should not judge code from decades ago, but then, with all the new standards (C99 comes to mind), I'm still surprised this function didn't get refactored.

At the very least, the strtok_s family of function produced by Microsoft uses a user-provided variable for that (called context). If you have the choice, for production code, use strtok_s.

And if you need to provide cross platform code, my advice is :

  1. write a function which will be used as an indirection to the real one
  2. On Windows, redirect to strtok_s
  3. On whatever platform where there is a safe strtok (I found strtok_r when Googling), redirect to that function
  4. On platforms where there are not safe strtok, write your own (it's far from being difficult, and is a good exercise to learn programming)

Now, there are C++ alternatives to these C functions, either combining std::string methods together, or using boost::tokenizer

paercebal
  • 81,378
  • 38
  • 130
  • 159
  • I need to make this as my answer. Thanks – munish May 15 '11 at 11:32
  • 1
    Of course, the C committee had learned from the past and designed `wcstok()` to be re-entrant (without the problem diagnosed for `strtok()`). There already was in many circles (POSIX-ish ones) a function `strtok_r()` which achieves reentrancy (that's what the `_r` suffix indicates). Hmmm...I see that the MSDN version of `wcstok()` does not match the C99 version of `wcstok()` - MSDN does continue the defects of `strtok()`. Ouch! Did not know that. Someone, some day, will explain where the buffer overrun comes from. I don't see the `*tok()` functions having buffer overrun issues... – Jonathan Leffler May 15 '11 at 11:44
  • 1
    @Jonathan Leffler : I guess Microsoft's `wcstok` was written as a mirror to `strtok` when working on Unicode Windows API (which uses UTF-16), probably years before C99's `wcstok`, and many years before Microsoft learned the hard way that security matters, even in code. – paercebal May 15 '11 at 11:51
  • 1
    @Jonathan Leffler : `I don't see the *tok() functions having buffer overrun issues` : I agree... Unless, with a little imagination. For example, someone feeds strtok with a pointer to non-zero terminated string (e.g. some random memory, probably not a string...). But even in this case, the cause for the buffer overrun is not within strtok, but (as a colleague of mine likes to say it) between the chair and the keyboard. – paercebal May 15 '11 at 12:01
  • 1
    @paercebal: I believe `wcstok()` was added to the standard in the C94 amendment to C89; I don't know when Microsoft's first implementation was released; it might have been before the standard. And [PEBKAC](http://www.acronymfinder.com/PEBKAC.html) is a common problem (I suffer occasionally, too). – Jonathan Leffler May 15 '11 at 12:19
  • nice discussion and PEBKAC,hmm...thats a problem!.Thanks guys – munish May 15 '11 at 12:44
1

The wcstok is susceptible to buffer overrun exploits. The compiler is recommending that you use an alternative version that deals with that threat.

Please refer to the remarks in the MSDN documentation for wcstok.

If you have complete control of the data which is passed to wcstok then you have no cause for concern. If the data passed to wcstok could be supplied by the user then that creates the potential for a buffer overrun attack.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • David, so theses functions wcstok,wcscpy...etc deprecated/obsolete .so i guess there should never be a situation where we have to use these obsolete functons instead we should use their safer versions.right!!.I should not be knowing about these obsolete stuff and just forget it if i don't need it anywhere else... – munish May 15 '11 at 09:52
  • 3
    @Munish: the old interfaces are deprecated by Microsoft but are still standard C (and hence C++). The C standards committee created a technical report TR24731-1 (see [Do you use the TR24731 safe functions](http://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions)) describing the alternative (`*_s()`) interfaces. Microsoft's implementation doesn't match the TR's definition exactly, sadly. And few compilers other than MSVC have implemented them. In some cases, the new calls are better than the ones they replace; in other cases, the benefit is minimal. – Jonathan Leffler May 15 '11 at 10:05
  • hmm...,so many variations from the standard C/C++.I need to know whats standard C/C++ learn it. thanks – munish May 15 '11 at 10:16
  • 2
    @munish: just to be totally clear, these `_s` functions are *NOT* standard, and these functions are in contrast to what MS wants you to believe, *NOT* deprecated in any official document. A lot of people on SO recommend to disable these warnings, and the define you need for that is `_CRT_SECURE_NO_WARNINGS`. Use the standard functions and this define if you know what you're doing, which you most probably do. – rubenvb May 15 '11 at 10:26
  • @rubenvb If you are wanting your code to defend against buffer overrun exploits you need to take action of some form or another. – David Heffernan May 15 '11 at 10:29
  • @David: [This question](http://stackoverflow.com/questions/372980/do-you-use-the-tr-24731-safe-functions) provides a good read on the subject. The fact that the MS implementation is not aligned to the proposal makes them non-portable/standard and the number of cons are actually quite frightening. – rubenvb May 15 '11 at 10:37
  • @rubenvb thanks, but still the important question is still buffer overun exploits as mentioned by David-->"**you need to take action of some form or another**".but if MS has its own enhanced version of the functions, I dont know about other companies/compilers they might have their own or they might be using the standard C++ as you mentioned. – munish May 15 '11 at 11:24