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.