Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: function pointer question
Date: Wed, 07 Jan 2026 05:59:39 -0800
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <86fr8hplpw.fsf@linuxsc.com>
References: <10j7rs6$7c9e$1@dont-email.me> <20260102091518.226@kylheku.com> <10j96mn$jrsp$1@dont-email.me> <10jc4n0$1ijf2$1@dont-email.me> <10jftcp$2locm$3@dont-email.me> <10jivdb$3p6r2$1@dont-email.me> <10jj0v8$3oje5$1@dont-email.me> <10jj7g5$1ba5e$1@paganini.bofh.team> <10jjs6h$4hqv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 07 Jan 2026 13:59:44 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="96c89593a79aadfcc4daf354c711affa"; logging-data="723889"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX183YcDZPZNdtF5Hcja+S7YUFTziXjPPVS8="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:mvjgJZsgp65n+rjQaZ7vn31ht5E= sha1:utZGlNHZzr4axsi1/beyMsSLCVA=
Xref: csiph.com comp.lang.c:396263
scott@slp53.sl.home (Scott Lurndal) writes:
> highcrew writes:
>
>> On 1/6/26 3:50 PM, Waldek Hebisch wrote:
>>
>>> Well, '(void)*foo' effectively says "foo" is not a null pointer
>>> (otherwise if would be undefined behaviour). Good optimizer
>>> will_not_ dereference foo, but keep information for further
>>> use.
>>
>> Hehe, now that I understand more of UB, that is correct, but
>> I don't think you can *rely* on the optimizer behavior, can you?
>
> Say you have a function xxx defined in a header file, but that
> function is only used in certain source files that include that
> header file.
>
> int
> xxx(const char *a, size_t b)
> {
> /* do something with a and b */
> }
>
> When compiling with -Wall, a translation unit that doesn't
> reference 'xxx' yet requires other components of the
> header file will get a warning (error with -Werror) that
> the function was unreferenced. It is not uncommon to
> make a void reference to the function in those translation
> units to avoid the warning, e.g.
>
> yyy.c:
>
> #include "xxx.h"
>
> int
> yyy(...)
> {
>
> (void)xxx;
> }
It seems better to address this problem in the header file
itself. It's easy to do that by adding a second function
in the header file and having them mutually reference
each other.
> xxx in this context devolves to a function pointer, IIUC.
Just use (void)&xxx. Now you're sure.