From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Amit Langote <amitlangote09(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP Incremental JSON Parser |
Date: | 2024-04-09 16:41:44 |
Message-ID: | CAOYmi+mm_P6Fh-kVhFDeBFWwn8ytGYCwx=tvXSgvNbHWr+p3RQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 8, 2024 at 10:24 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> At the end, having a way to generate JSON blobs randomly to test this
> stuff would be more appealing
For the record, I'm working on an LLVM fuzzer target for the JSON
parser. I think that would be a lot more useful than anything we can
hand-code.
But I want it to cover both the recursive and incremental code paths,
and we'd need to talk about where it would live. libfuzzer is seeded
with a bunch of huge incomprehensible blobs, which is something we're
now trying to avoid checking in. There's also the security aspect of
"what do we do when it finds something", and at that point maybe we
need to look into a service like oss-fuzz.
Thanks,
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-04-09 17:10:07 | Re: IPC::Run::time[r|out] vs our TAP tests |
Previous Message | Peter Geoghegan | 2024-04-09 16:40:28 | Re: post-freeze damage control |