Re: Warning -Wclobbered in PG_TRY(...)
От | Tom Lane |
---|---|
Тема | Re: Warning -Wclobbered in PG_TRY(...) |
Дата | |
Msg-id | 2019232.1748532037@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Warning -Wclobbered in PG_TRY(...) (Maxim Orlov <orlovmg@gmail.com>) |
Ответы |
Re: Warning -Wclobbered in PG_TRY(...)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: