> On 19 Dec 2013, at 02:05, Nicolás Alvarez <[email protected]> wrote: > > 2013/12/18 Kurt Pattyn <[email protected]>: >> For a lot of the standard C functions, Microsoft has implemented "safe" >> versions. >> Functions like sprintf, scanf, strcpy, aso have "safe" counterparts with an >> _s suffix: sprintf_s, scanf_s, aso >> When the "non-safe" functions are used, the Microsoft compiler generates a >> warning that these functions should be replaced by their "safe" counterparts. >> There are 3 ways to get rid of these warnings: >> 1. replacing those functions, >> 2. using a #pragma >> 3. using a compiler flag >> >> What is the recommended way to get rid of these warnings in the Qt sources? >> >> I solved these warnings by replacing the calls with the safe versions, but >> the patch was rejected because it was recommended to use #pragmas. >> Before proceeding and going through the sources again, I would like to know >> the recommended practice within Qt. > > The so-called safe functions with the _s are Microsoft extensions and > don't exist in other platforms. Changing to the "recommended" "safe" > functions makes the code only compile and work on Windows.
Yes, I am aware of that. Those functions are put within #ifdef statements. > > I don't know how Qt handles this, but in other projects the solution > I've seen is to just define _CRT_SECURE_NO_WARNINGS globally. Qt uses qXXX() functions for a lot of those function: qstrcpy, qstrcmp, aso. Those functions expand to the "safe" counterparts when using MSVC. Some functions like strerror() cannot be simply replaced by such a wrapper, because their signature is too different. Defining _CRT_SECURE_NO_WARNINGS is an option as far as only the private code would be affected, but this cannot be guaranteed. If an "unsecure" method is used in a public file, users of the API don't have the option to detect those warnings. In some regulatory markets, people can be forced to actually do something about those warnings, and not just hide them. After all, if Microsoft says it's unsafe, then it must be really unsafe, isn't it ;-) In the regulatory case, people need to patch Qt by removing all suppressions and fix the warnings (and that's a huge undertaking). That's why I want to know what the 'official' statement is from the Qt community regarding this issue. I replaced the "unsecure" functions with their "secure" counterparts, but that patch was rejected. Now, before going through the code again, I want to be sure that I am doing it right this time. > > -- > Nicolás _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
