Re: warn_unused_results

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: warn_unused_results
Date: 2020-11-09 07:23:31
Message-ID: 8ef6a7dc-5ea1-46b3-4406-7be7d07886f0@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-11-09 07:53:41 Re: pg_upgrade analyze script
Previous Message Michael Paquier 2020-11-09 06:56:06 Re: warn_unused_results