Re: warn_unused_results
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-09T07:23:31Z
Lists: pgsql-hackers
On 2020-11-09 07:56, Michael Paquier wrote: > This is accepted by clang, and MSVC has visibly an equivalent for > that, as of VS 2012: > #elif defined(_MSC_VER) && (_MSC_VER >= 1700) > #define pg_nodiscard _Check_return_ > We don't care about the 1700 condition as we support only >= 1800 on > HEAD, and in this case the addition of pg_nodiscard would be required > on the definition and the declaration. Should it be added? It is > much more invasive than the gcc/clang equivalent though.. AFAICT from the documentation, this only applies for special "analyze" runs, not as a normal compiler warning. Do we have any support for analyze runs with MSVC? > FWIW, I saw an extra case with parsePGArray() today. AFAICT, that's more in the category of checking for error returns, which is similar to the "fortify" options that some environments have for checking the return of fwrite() etc. > I am not sure > about the addition of repalloc(), as it is quite obvious that one has > to use its result. Lists are fine, these are proper to PG internals > and beginners tend to be easily confused in the way to use them. realloc() is listed in the GCC documentation as the reason this option exists, and glibc tags its realloc() with this attribute, so doing the same for repalloc() seems sensible. -- Peter Eisentraut 2ndQuadrant, an EDB company https://www.2ndquadrant.com/
Commits
-
Add pg_nodiscard decorations to some functions
- a378ba49a5cf 14.0 landed
-
Add pg_nodiscard function declaration specifier
- c617aea6acdd 14.0 landed
-
Fix cases of discarding result from list API functions
- c77f6f50e418 14.0 landed