Ошибка c6031 c

As @SteveSummit indicates in a comment, most C implementations have a mechanism to identify functions whose return value should not be ignored.

C itself (as defined by the C standard) has always allowed a caller to ignore the return value of a function. It even allows a function declared with a return value type to not return any value as long as all callers ignore the return value.

However, that permissiveness does not generally lead to good programming practice. In some cases, it is very likely that ignoring the return value of a function will lead to a bug. scanf is considered to be such a function, so the authors of standard libraries tend to mark scanf as requiring that the return value be used.

There is no standard way to mark a function as requiring use of their return values. In GCC and Clang, this is done using the attribute warn_unused_result:

int fn (int a) __attribute__ ((warn_unused_result));

(See the GCC documentation for the warn_unused_result function attribute and how to turn off the warning (not recommended): the `-Wno-unused-result.)

In MSVC, it’s done with the _Check_return_ macro, found in sal.h:

#include <sal.h>
_Check_return_ int fn (int a);

(See the Visual Studio docs for error C6031 and this documenation on the Source Annotation Library (sal).)

There are good reasons not to ignore the return value of any library function which uses the return value to indicate failure, including many standard library functions which do input or output. Ignoring input or output failure can lead to problems, but the problems are more evident when ignoring input failure because that can lead to the use of uninitialised values, which in turn can lead to Undefined Behaviour. That is certainly the case for scanf: ignoring its return value means that your program will not respond correctly to malformed input, which is almost certainly a bug.

Ignoring the failure of output functions will sometimes mean that the user is not warned about failure to save persistent data. That can be serious, and it may well be that some action needs to be taken to save that data. But in other cases, the error simply means that the user didn’t see some logging message and most likely will not see future logging messages either. This might not be considered important.

As @SteveSummit indicates in a comment, most C implementations have a mechanism to identify functions whose return value should not be ignored.

C itself (as defined by the C standard) has always allowed a caller to ignore the return value of a function. It even allows a function declared with a return value type to not return any value as long as all callers ignore the return value.

However, that permissiveness does not generally lead to good programming practice. In some cases, it is very likely that ignoring the return value of a function will lead to a bug. scanf is considered to be such a function, so the authors of standard libraries tend to mark scanf as requiring that the return value be used.

There is no standard way to mark a function as requiring use of their return values. In GCC and Clang, this is done using the attribute warn_unused_result:

int fn (int a) __attribute__ ((warn_unused_result));

(See the GCC documentation for the warn_unused_result function attribute and how to turn off the warning (not recommended): the `-Wno-unused-result.)

In MSVC, it’s done with the _Check_return_ macro, found in sal.h:

#include <sal.h>
_Check_return_ int fn (int a);

(See the Visual Studio docs for error C6031 and this documenation on the Source Annotation Library (sal).)

There are good reasons not to ignore the return value of any library function which uses the return value to indicate failure, including many standard library functions which do input or output. Ignoring input or output failure can lead to problems, but the problems are more evident when ignoring input failure because that can lead to the use of uninitialised values, which in turn can lead to Undefined Behaviour. That is certainly the case for scanf: ignoring its return value means that your program will not respond correctly to malformed input, which is almost certainly a bug.

Ignoring the failure of output functions will sometimes mean that the user is not warned about failure to save persistent data. That can be serious, and it may well be that some action needs to be taken to save that data. But in other cases, the error simply means that the user didn’t see some logging message and most likely will not see future logging messages either. This might not be considered important.

// compile with: /Wall
#include <Windows.h>
#include <cwchar>       // std::wcsrchr
#include <comdef.h>     // _com_error
#include <iostream>     // std::cin

// Show only file name instead of full path wide version
#define __FILENAME__ (std::wcsrchr(TEXT(__FILE__), L'\') ? std::wcsrchr(TEXT(__FILE__), L'\') + 1 : TEXT(__FILE__))

// Writes a sprintf-formatted string to the logging file.
#define TRACE(...) DebugLogTrace(__VA_ARGS__)

// Log HRESULTs if failed.
#define LOG_IF_FAILED(file_name, line, hr) if constexpr (FAILED(hr)) 
    { TRACE((TEXT("%s %i %s"), file_name, line, _com_error(hr).ErrorMessage())); }

// Writes a sprintf-formatted string to the logging file.
void DebugLogTrace(PCTSTR format_string, ...) noexcept
{
    // implementation not important
}

int main()
{
      // generate example failure
      LOG_IF_FAILED(__FILENAME__, __LINE__, E_FAIL);

      std::cin.get();
      return 0;
}

1 ответ

Лучший ответ

#define LOG_IF_FAILED(file_name, line, hr) if constexpr (FAILED(hr)) 
    { TRACE((TEXT("%s %i %s"), file_name, line, _com_error(hr).ErrorMessage())); }

#define LOG_IF_FAILED(file_name, line, hr) if constexpr (FAILED(hr)) 
    { TRACE(TEXT("%s %i %s"), file_name, line, _com_error(hr).ErrorMessage()); }