| From: | "Tristan Partin" <tristan(at)partin(dot)io> |
|---|---|
| To: | "Daniel Gustafsson" <daniel(at)yesql(dot)se> |
| Cc: | "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Grab bag of smaller OpenSSL fixups |
| Date: | 2026-07-14 20:46:27 |
| Message-ID: | DJYL6YIYU7S3.3RBM310C276GU@partin.io |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue Jul 14, 2026 at 7:49 AM UTC, Daniel Gustafsson wrote:
>> On 13 Jul 2026, at 22:38, Tristan Partin <tristan(at)partin(dot)io> wrote:
>> I did have one comment in patch 0001. For the
>> hasWarned argument to init_host_context, do we you think we should add
>> an Assert(hasWarned) or add a pg_attribute_nonnull(3)? I see we
>> dereference the pointer without first checking for its validity. I know
>> it isn't common in Postgres source code to add such protections, but
>> I figured I would point it out anyway.
>
> Given that this is a very niche static function with very few callsites, I'm
> not too worried about it being called with NULL. That being said, defensive
> programming isn't just to defend against what we know but also what we don't
> know about so I'm not against adding such protections. There are likely many
> other functions in this file which could benefit more from pg_attribute_nonnull
> but we also need to start somewhere.
Indeed. There are places all over the codebase that would likely benefit
from pg_attribute_nonnull. Choosing when to add the annotation takes
a bit of thought.
--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-07-14 20:46:41 | Re: hashjoins vs. Bloom filters (yet again) |
| Previous Message | Nico Williams | 2026-07-14 19:52:27 | Re: document the dangers of granting TRIGGER or REFERENCES |