| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Silence -fsanitize=function where we cast function pointers on purpose |
| Date: | 2026-10-04 14:59:02 |
| Message-ID: | 936c96c4-3fd2-4d64-995b-31e57b6ba0ee@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 29.09.26 12:01, Peter Eisentraut wrote:
> On 29.09.26 11:18, Chao Li wrote:
>>> On Sep 29, 2026, at 13:47, Peter Eisentraut <peter(at)eisentraut(dot)org>
>>> wrote:
>>>
>>> In clang, -fsanitize=undefined includes -fsanitize=function, which
>>> reports every call made through a function pointer whose type does
>>> not exactly match the called function, so it fires all over the place
>>> on expression tree walkers and mutators, as well as a few other
>>> places. So -fsanitize=undefined hasn't been working cleanly under
>>> clang for a while. (Before clang 17, it only applied to C++.)
>>>
>>> This is the same issue that caused us to use -Wno-cast-function-type-
>>> strict with clang. That warning applies at the place where the
>>> mismatching function pointer is passed, so there are potentially
>>> hundreds of sites. Therefore, a global disabling is appropriate.
>>> The sanitizer, on the other hand, triggers where the function is
>>> called, which are only about two dozen places, so it seems possible
>>> to silence these checks individually and still main the check for
>>> accidental violations elsewhere.
>>>
>>> I propose to add pg_attribute_no_sanitize_function() and place it on
>>> the functions that make such calls. This is similar to some existing
>>> pg_attribute_no_sanitize_xxx attributes.
>>> <0001-Silence-fsanitize-function-where-we-cast-function-po.patch>
>>
>> Overall looks good to me.
>>
>> Just one comment, in dynahash.c, hash_search_with_hash_value() is
>> marked with the new annotation, feels like hash_update_hash_key() also
>> needs to be annotated, because it also invokes match and keycopy etc
>> callbacks.
>
> Yes, I think you are right. My patch was based on what is required to
> get the test suite to pass. It appears that there are currently no
> callers of hash_update_hash_key() with a string-based hash table, so
> this case isn't triggered, but we should add the annotation there as
> well for completeness.
Committed with that change.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rui Zhao | 2026-10-04 15:50:44 | Re: Serverside SNI support in libpq |
| Previous Message | Tatsuya Kawata | 2026-10-04 14:52:21 | Table Function Scan can report incorrect "Maximum Storage" in EXPLAIN |