Re: warn_unused_results - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: warn_unused_results
Date
Msg-id 8ef6a7dc-5ea1-46b3-4406-7be7d07886f0@2ndquadrant.com
Whole thread Raw
In response to Re: warn_unused_results  (Michael Paquier <michael@paquier.xyz>)
Responses Re: warn_unused_results
List 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/



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: warn_unused_results
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade analyze script