Re: Silence -fsanitize=function where we cast function pointers on purpose

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.

In response to

Browse pgsql-hackers by date

  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