类似“wcstok”的警告:此函数或变量可能不安全。考虑使用 wcstok_s 代替

发布于 2024-11-07 07:42:40 字数 1470 浏览 0 评论 0原文

我只是在代码中使用这些宽字符文字来了解它们

     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");

为什么我会收到这些警告,无论如何我都忽略了它。 我们是否需要忽略任何此类警告?

    : 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'

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'

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

绅士风度i 2024-11-14 07:42:41

不使用原始的 strtok 系列函数还有另一个原因:

[...] 但是,在单个线程内,对这些函数之一的交错调用很可能会产生数据损坏和不准确的结果。解析不同的字符串时,先解析完一个字符串,然后再开始解析下一个字符串。另外,请注意在调用另一个函数的循环内调用其中一个函数时可能存在的危险。如果另一个函数最终使用这些函数之一,则会产生交错的调用序列,从而触发数据损坏。

原因是 strtok 不可重入:在设计时,人们认为使用全局变量作为上下文的存储库是一个好主意(您认为 strtok< /code> 能记住每个函数调用之间从哪里继续吗?)。

过去的已经过去了,我们不应该评判几十年前的代码,但是,随着所有新标准(我想到了 C99),我仍然对这个函数没有被重构感到惊讶。

至少,Microsoft 生成的strtok_s 函数系列使用了用户为此提供的变量(称为context)。如果您可以选择,对于生产代码,请使用 strtok_s

如果您需要提供跨平台代码,我的建议是:

  1. 编写一个函数,该函数将用作真实函数的间接函数
  2. 在 Windows 上,重定向到 strtok_s
  3. 在任何有安全 strtok 的平台上(我发现 strtok_r 当谷歌搜索时),重定向到该函数
  4. 在没有安全strtok的平台上,编写自己的函数(这远非困难,并且是学习编程的一个很好的练习)

现在,有这些函数的C++替代品C 函数,将 std::string 方法组合在一起,或使用 boost::tokenizer

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

○闲身 2024-11-14 07:42:41

您应该使用 std::wstringstd::string 以及类似的 C++ 标准库函数,而不是这些函数,因为它们容易受到缓冲区溢出和其他安全问题的影响 (更不用说应用程序可靠性)问题。

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.

风尘浪孓 2024-11-14 07:42:41

wcstok 容易受到缓冲区溢出攻击。编译器建议您使用应对该威胁的替代版本。

请参考MSDN文档中的备注对于wcstok

如果您可以完全控制传递给 wcstok 的数据,那么您就无需担心。如果传递给 wcstok 的数据可以由用户提供,则可能会造成缓冲区溢出攻击。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文