Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robin Haberkorn <haberkorn(at)b1-systems(dot)de>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, pgsql-bugs(at)lists(dot)postgresql(dot)org, maralist86(at)mail(dot)ru
Subject: Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL
Date: 2025-07-08 13:36:37
Message-ID: 689495.1751981797@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Tue, Jul 08, 2025 at 09:49:20AM +0000, Robin Haberkorn wrote:
>> I know this has already been committed, but why are we still using
>> PG_XML_STRICTNESS_LEGACY in xpath.c? As we are always checking
>> pg_xml_error_occurred() this should no longer be necessary.

> Are you sure that you can do that?

The comment in xml_errorHandler() argues

* Legacy error handling mode. err_occurred is never set, we just add the
* message to err_buf. This mode exists because the xml2 contrib module
* uses our error-handling infrastructure, but we don't want to change its
* behaviour since it's deprecated anyway. This is also why we don't
* distinguish between notices, warnings and errors here --- the old-style
* generic error handler wouldn't have done that either.

So switching to _ALL (or even _WELL_FORMED) mode would result in
nontrivial differences in the behavior of xpath.c's functions with
bad input. Maybe that's a reasonable thing to do, but it's a
question of user-visible behavior not just code cleanliness.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2025-07-08 16:42:00 Re: Unexpected behavior when setting "idle_replication_slot_timeout"
Previous Message Michael Paquier 2025-07-08 11:23:30 Re: BUG #18943: Return value of a function 'xmlBufferCreate' is dereferenced at xpath.c:177 without checking for NUL