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 in 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.
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, egarowana | 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 in 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, egarowana | 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 in 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