Thread: 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