Maxim Orlov <orlovmg@gmail.com> writes:
> On Thu, 29 May 2025 at 14:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> -Wclobbered would be really useful if it worked --- but sadly,
>> on practically all gcc and clang versions, those warnings have
>> nearly nothing to do with reality. We typically ignore them.
> Yes, in the vast majority of cases. But I believe this is not one of them.
> Actually, we do
> not adhere to the C language standard for a setjump/logjump.
Really? I don't have a current C standard at hand, but POSIX-2024 [1]
claims to be aligned with the C standard for this, and what it says
under "longjmp" is
All accessible objects have values, and all other components of
the abstract machine have state (for example, floating-point
status flags and open files), as of the time longjmp() was called,
except that the values of objects of automatic storage duration
are unspecified if they meet all the following conditions:
They are local to the function containing the corresponding
setjmp() invocation.
They do not have volatile-qualified type.
They are changed between the setjmp() invocation and longjmp() call.
That is pretty black-and-white, and the PG_TRY macros do not
change _do_rethrow between setjmp() and longjmp(). PG_FINALLY
will change it after return from longjmp(), but at that point
it doesn't matter. So if we need a volatile qualifier here,
it means the implementation fails to adhere to the C standard.
I'm not clear what conditions provoke the -Wclobbered warning,
but many cases seem to amount to "the value of the variable
gets changed before reaching PG_TRY". That again is not a
case that the implementation is allowed to call undefined.
regards, tom lane
