Re: pg_parse_json() should not leak token copies on failure

2024-11-27 Thread Andrew Dunstan
On 2024-10-31 Th 5:10 PM, Jacob Champion wrote: On Mon, Oct 7, 2024 at 3:45 PM Jacob Champion wrote: I've added a 0002 as well. 0002 has since been applied [1] so I'm reattaching v4-0001 to get the cfbot happy again. --Jacob [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=41b

Re: pg_parse_json() should not leak token copies on failure

2024-10-31 Thread Jacob Champion
On Mon, Oct 7, 2024 at 3:45 PM Jacob Champion wrote: > I've added a 0002 as well. 0002 has since been applied [1] so I'm reattaching v4-0001 to get the cfbot happy again. --Jacob [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=41b023946d v4-0001-jsonapi-add-lexer-option-to-keep-

Re: pg_parse_json() should not leak token copies on failure

2024-10-07 Thread Jacob Champion
On Wed, Oct 2, 2024 at 10:45 AM Andrew Dunstan wrote: > Generally looks good. Should we have a check in > setJsonLexContextOwnsTokens() that we haven't started parsing yet, for > the incremental case? Good catch. Added in v4. > > At the moment, we have a test matrix consisting of "standard front

Re: pg_parse_json() should not leak token copies on failure

2024-10-02 Thread Andrew Dunstan
On 2024-10-01 Tu 3:04 PM, Jacob Champion wrote: (Tom, thank you for the fixup in 75240f65!) Off-list, Andrew suggested an alternative approach to the one I'd been taking: let the client choose whether it wants to take token ownership to begin with. v3 adds a new flag (and associated API) which

Re: pg_parse_json() should not leak token copies on failure

2024-10-01 Thread Jacob Champion
(Tom, thank you for the fixup in 75240f65!) Off-list, Andrew suggested an alternative approach to the one I'd been taking: let the client choose whether it wants to take token ownership to begin with. v3 adds a new flag (and associated API) which will allow libpq to refuse ownership of those token

Re: pg_parse_json() should not leak token copies on failure

2024-06-04 Thread Michael Paquier
On Tue, Jun 04, 2024 at 10:10:06AM -0700, Jacob Champion wrote: > On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi > wrote: >> I understand that the part enclosed in parentheses refers to the "if >> (ptr) pfree(ptr)" structure. I believe we rely on the behavior of >> free(NULL), which safely does

Re: pg_parse_json() should not leak token copies on failure

2024-06-04 Thread Jacob Champion
On Mon, Jun 3, 2024 at 9:32 PM Kyotaro Horiguchi wrote: > > Hi, Thanks for the review! > I understand that the part enclosed in parentheses refers to the "if > (ptr) pfree(ptr)" structure. I believe we rely on the behavior of > free(NULL), which safely does nothing. (I couldn't find the related

Re: pg_parse_json() should not leak token copies on failure

2024-06-03 Thread Kyotaro Horiguchi
Hi, At Fri, 24 May 2024 08:43:01 -0700, Jacob Champion wrote in > On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion > wrote: > > Attached is a draft patch to illustrate what I mean, but it's > > incomplete: it only solves the problem for scalar values. > > (Attached is a v2 of that patch; in sol

Re: pg_parse_json() should not leak token copies on failure

2024-05-24 Thread Jacob Champion
On Tue, Apr 30, 2024 at 2:29 PM Jacob Champion wrote: > Attached is a draft patch to illustrate what I mean, but it's > incomplete: it only solves the problem for scalar values. (Attached is a v2 of that patch; in solving a frontend leak I should probably not introduce a backend segfault.) --Jac

pg_parse_json() should not leak token copies on failure

2024-04-30 Thread Jacob Champion
Hi, When a client of our JSON parser registers semantic action callbacks, the parser will allocate copies of the lexed tokens to pass into those callbacks. The intent is for the callbacks to always take ownership of the copied memory, and if they don't want it then they can pfree() it. However, i