Обсуждение: pgsql: Fix up misuse of "volatile" in contrib/xml2.
Fix up misuse of "volatile" in contrib/xml2. What we want in these places is "xmlChar *volatile ptr", not "volatile xmlChar *ptr". The former means that the pointer variable itself needs to be treated as volatile, while the latter says that what it points to is volatile. Since the point here is to ensure that the pointer variables don't go crazy after a longjmp, it's the former semantics that we need. The misplacement of "volatile" also led to needing to cast away volatile in some places. Also fix a number of places where variables that are assigned to within a PG_TRY and then used after it were not initialized or not marked as volatile. (A few buildfarm members were issuing "may be used uninitialized" warnings about some of these variables, which is what drew my attention to this area.) In most cases these variables were being set as the last step within the PG_TRY block, which might mean that we could get away without the "volatile" marking. But doing that seems unsafe and is definitely not per our coding conventions. These problems seem to have come in with 732061150, so no need for back-patch. Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/93001888d85c21a5b9ab1fe8dabfecb673fc007c Modified Files -------------- contrib/xml2/xpath.c | 49 ++++++++++++++++++++++++------------------------ contrib/xml2/xslt_proc.c | 10 +++++----- 2 files changed, 29 insertions(+), 30 deletions(-)
On Tue, Jul 08, 2025 at 09:00:39PM +0000, Tom Lane wrote: > Fix up misuse of "volatile" in contrib/xml2. > > Also fix a number of places where variables that are assigned to > within a PG_TRY and then used after it were not initialized or > not marked as volatile. (A few buildfarm members were issuing > "may be used uninitialized" warnings about some of these variables, > which is what drew my attention to this area.) In most cases > these variables were being set as the last step within the PG_TRY > block, which might mean that we could get away without the "volatile" > marking. But doing that seems unsafe and is definitely not per our > coding conventions. > > These problems seem to have come in with 732061150, so no need > for back-patch. Oops, thanks. I was not aware of these reports, and the buildfarm was not showing any red, the CI looked fine and my machine did not complain with a rather new gcc. What were the buildfarm members impacted? Did these use a switch and/or a specific compiler that helped in detecting these problems? -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Jul 08, 2025 at 09:00:39PM +0000, Tom Lane wrote:
>> Also fix a number of places where variables that are assigned to
>> within a PG_TRY and then used after it were not initialized or
>> not marked as volatile. (A few buildfarm members were issuing
>> "may be used uninitialized" warnings about some of these variables,
>> which is what drew my attention to this area.)
> Oops, thanks. I was not aware of these reports, and the buildfarm was
> not showing any red, the CI looked fine and my machine did not
> complain with a rather new gcc. What were the buildfarm members
> impacted? Did these use a switch and/or a specific compiler that
> helped in detecting these problems?
Not sure. Yesterday I saw such warnings from arowana,
boa, dhole, rhinoceros, and shelduck, eg
arowana | 2025-07-08 04:54:18 | xpath.c:274:6: warning: 'workspace' may be used uninitialized in this function
[-Wmaybe-uninitialized]
arowana | 2025-07-08 04:54:18 | xpath.c:319:6: warning: 'workspace' may be used uninitialized in this function
[-Wmaybe-uninitialized]
arowana | 2025-07-08 04:54:18 | xpath.c:374:6: warning: 'workspace' may be used uninitialized in this function
[-Wmaybe-uninitialized]
arowana | 2025-07-08 04:54:18 | ../../src/include/postgres.h:329:2: warning: 'result' may be used uninitialized
inthis function [-Wmaybe-uninitialized]
Didn't look to try to figure out what the common factor
among these machines is, but I think all of them are somewhat
dated, which is depressing. You'd hope that newer compilers
are more likely to find such issues, not less likely.
regards, tom lane
On Wed, Jul 09, 2025 at 11:49:55AM -0400, Tom Lane wrote: > Not sure. Yesterday I saw such warnings from arowana, > boa, dhole, rhinoceros, and shelduck, eg > > arowana | 2025-07-08 04:54:18 | xpath.c:274:6: warning: 'workspace' may be used uninitialized in this function [-Wmaybe-uninitialized] > arowana | 2025-07-08 04:54:18 | xpath.c:319:6: warning: 'workspace' may be used uninitialized in this function [-Wmaybe-uninitialized] > arowana | 2025-07-08 04:54:18 | xpath.c:374:6: warning: 'workspace' may be used uninitialized in this function [-Wmaybe-uninitialized] > arowana | 2025-07-08 04:54:18 | ../../src/include/postgres.h:329:2: warning: 'result' may be used uninitializedin this function [-Wmaybe-uninitialized] > > Didn't look to try to figure out what the common factor > among these machines is, but I think all of them are somewhat > dated, which is depressing. You'd hope that newer compilers > are more likely to find such issues, not less likely. They are all using some gcc 4.X flavor, most with -O2 but not all. And -Wmaybe-uninitialized is included in my default switches with a gcc 14, and there is nothing with several levels of optimizations applied, up to -O3. :( -- Michael
Вложения
On Wed, Jul 9, 2025 at 8:55 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jul 09, 2025 at 11:49:55AM -0400, Tom Lane wrote: > > Not sure. Yesterday I saw such warnings from arowana, > > boa, dhole, rhinoceros, and shelduck, eg > > > > arowana | 2025-07-08 04:54:18 | xpath.c:274:6: warning: 'workspace' may be used uninitialized in this function[-Wmaybe-uninitialized] > > arowana | 2025-07-08 04:54:18 | xpath.c:319:6: warning: 'workspace' may be used uninitialized in this function[-Wmaybe-uninitialized] > > arowana | 2025-07-08 04:54:18 | xpath.c:374:6: warning: 'workspace' may be used uninitialized in this function[-Wmaybe-uninitialized] > > arowana | 2025-07-08 04:54:18 | ../../src/include/postgres.h:329:2: warning: 'result' may be used uninitializedin this function [-Wmaybe-uninitialized] > > > > Didn't look to try to figure out what the common factor > > among these machines is, but I think all of them are somewhat > > dated, which is depressing. You'd hope that newer compilers > > are more likely to find such issues, not less likely. > > They are all using some gcc 4.X flavor, most with -O2 but not all. > > And -Wmaybe-uninitialized is included in my default switches with a > gcc 14, and there is nothing with several levels of optimizations > applied, up to -O3. :( I think I remember that GCC has had historical problems with tuning the false-positive:false-negative rates for `-Wmaybe-uninitialized`. It's not super surprising to me that later versions aren't always better at seeing specific problems, especially if users were complaining that an earlier version was too sensitive... --Jacob
Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Wed, Jul 9, 2025 at 8:55 PM Michael Paquier <michael@paquier.xyz> wrote:
>> On Wed, Jul 09, 2025 at 11:49:55AM -0400, Tom Lane wrote:
>>> Not sure. Yesterday I saw such warnings from arowana,
>>> boa, dhole, rhinoceros, and shelduck, eg
>> They are all using some gcc 4.X flavor, most with -O2 but not all.
> I think I remember that GCC has had historical problems with tuning
> the false-positive:false-negative rates for `-Wmaybe-uninitialized`.
> It's not super surprising to me that later versions aren't always
> better at seeing specific problems, especially if users were
> complaining that an earlier version was too sensitive...
Yeah. Worth noting also is that even the machines that were
complaining were warning about just a subset of the xpath.c functions
that had this problem :-(. So there's definitely some heuristics
involved, which seems odd for what feels like it ought to be a
pretty black-and-white condition.
regards, tom lane