Msvc Equivalent of _Attribute_ ((Warn_Unused_Result))

MSVC equivalent of __attribute__ ((warn_unused_result))?

It's _Check_return_. See here for examples of similar annotations and here for function behaviour. It's supported since MSVC 2012.

Example:

_Check_return_
int my_return_must_be_checked() {
    return 42;
}

Visual studio equivalent for __attribute__ ((warn_unused_result))

The annotation is _Check_return_

Annotates a return value and states that the caller should inspect it. The checker reports an error if the function is called in a void context.

However, I believe SAL annotations are only available in the Premium and Ultimate versions of Visual Studio.

MSDN: Annotating Function Behavior

__attribute__ ((warn_unused_result)) does not produce warnings for shared_ptr

This evidently is a compiler bug specific to C++ that is present until GCC 6.3
and fixed in GCC 7.1. Upgrading GCC would seem to be your
only solution.

__attribute_warn_unused_result__ vs __attribute__((warn_unused_result))

GCC supports this attribute since 3.4 so that __attribute_warn_unused_result__ defined as __attribute__((warn_unused_result)) or empty depend on GCC version (see sys/cdefs.h).

Search __attribute_warn_unused_result__ definition in your programming system.

Update:

Attribute warn_unused_result is a feature of the compiler.
Any GCC compiler since 3.4 will recognize and use __attribute__((warn_unused_result)).
But this feature may not be supported by other compilers or may be specified otherwise.

On the other hand, the __attribute_warn_unused_result__ macro defined in library header file.
Purposes — the ability to remove an attribute for non-supported compilers; the hide implementation details and specify this property in another way.

But this macro depends on library implementation.
For example, the macro not present at all in arm-none-eabi-gcc 4.9.3 and avr-gcc 4.9.2 packages, just as in mingw32-gcc 3.4.2 which I still use for one "ancient" project.

For gcc-linaro-7.2.1-2017.11-x86_64_arm-eabi similar purpose macros defined as

#define __result_use_check  __attribute__((__warn_unused_result__))

But in gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf package the definition (a whole sys/cdefs.h file) is the same as for "native" gcc in Ubuntu 16.04.

#define __attribute_warn_unused_result__ \
    __attribute__ ((__warn_unused_result__))

Hence, which one approach supercedes another one depends on the goals.
On my opinion:

• For code that supposed to be used with GCC (>= 3.4) across a couple of platforms it is better to use explicit __attribute__((__warn_unused_result__)).

• For code that supposed to be compiled by a couple of compilers that may not support this feature or may support it in different way it is better to use some macro (may be even self-defined).

• For already existing project it is better to use the approach mostly used in present code :-)

About autocompletion with different behavior for header and source files.
I don't know. May be it is just originality of specific IDE (autocompletion).

Casting to void doesn't remove warn_unused_result error

Why not simply use the result, as the warning suggests you should.

if (freopen("/dev/null", "w", stderr) == 0)
    ...oops...lost stderr...hard to report errors...

Since the function is declared with the 'warn_unused_result' attribute, you will get the warning unless you use the return value. Since the function either returns null on failure or the file stream argument on success, you might think about assigning the result. However, you should not
assign to stderr like that (see below), so this is a bad idea:

stderr = freopen("/dev/null", "w", stderr);

Theoretically, you should make that check; there are dire (and implausible) circumstances under which you could fail to open "/dev/null".

---

Footnote 229 in the C99 standard notes:

²²⁹⁾ The primary use of the freopen function is to change the file associated with a standard text stream
(stderr, stdin, or stdout), as those identifiers need not be modifiable lvalues to which the value
returned by the fopen function may be assigned.

Therefore, the assignment is ill-advised. But testing the return value would deal with the compiler warning and might help prevent core dumps too. It is unlikely to improve your code coverage figures, though (the error path is not going be taken very often; it will be hard to force coverage of the error handling).

Note that the POSIX description of freopen() has some moderately caustic comments about the design of freopen(), which was invented by the C standard committee (1989 version), presumably without input from POSIX.

MSVC equivalent to __builtin_popcount?

Using the comments provided:

• __popcnt available through <intrin.h>
• _mm_popcnt_u64 with SSE4 and <nmmintrin.h>

g++ How to get warning on ignoring function return value

Thanks to WhirlWind and paxdiablo for the answer and comment. Here is my attempt to put the pieces together into a complete (?) answer.

-Wunused-result is the relevant gcc option. And it is turned on by default. Quoting from gcc warning options page:

-Wno-unused-result

Do not warn if a caller of a function marked with attribute warn_unused_result (see
Variable Attributes) does not use its return value. The default is -Wunused-result

So, the solution is to apply the warn_unused_result attribute on the function.

Here is a full example. The contents of the file unused_result.c

int foo() { return 3; }

int bar() __attribute__((warn_unused_result));
int bar() { return 5; }

int main()
{
    foo();
    bar();    /* line 9 */
    return 0;
}

and corresponding compilation result:

$gcc unused_result.c 
unused_result.c: In function ‘main’:
unused_result.c:9: warning: ignoring return value of ‘bar’, declared with attribute warn_unused_result

Note again that it is not necessary to have -Wunused-result since it is default. One may be tempted to explicitly mention it to communicate the intent. Though that is a noble intent, but after analyzing the situation, my choice, however, would be against that. Because, having -Wunused-result in the compile options may generate a false sense of security/satisfaction which is not true unless the all the functions in the code base are qualified with warn_unused_result.

MSVC equivalent to '__builtin_return_address'

__ReturnAddress

From MSDN:

The _ReturnAddress intrinsic provides
the address of the instruction in the
calling function that will be executed
after control returns to the caller

Note that on some platforms, the result could be misleading due to tail folding - the compiler might have your inner function return 2 levels deep. This can commonly occur for code like this:

int DoSomething()
{
   return DoSomethingSpecial();
}

The compiler could generate code so DoSomethingSpecial returns directly to the caller of DoSomething.

Also, the return address is not trustworthy-enough to make security decisions, see here.

---

Related Topics