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 18:44:05 -0800 Organization: A noiseless patient Spider Lines: 35 Message-ID: <86ldi8ombu.fsf@linuxsc.com> References: <10j7rs6$7c9e$1@dont-email.me> <20260102091518.226@kylheku.com> <10j96mn$jrsp$1@dont-email.me> <10j9enb$p6ts$2@dont-email.me> <10j9g71$pr9o$1@dont-email.me> <10jb3j5$17gcb$3@dont-email.me> <10jbsp0$1gf7e$1@dont-email.me> <10jc02j$1hk1n$1@dont-email.me> <86bjj5phai.fsf@linuxsc.com> <10jm0ul$oq53$1@dont-email.me> <10jm1a1$pfer$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Thu, 08 Jan 2026 02:44:09 +0000 (UTC) Injection-Info: dont-email.me; posting-host="f646824e109d26d154da12d2f3c25277"; logging-data="1245349"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+L23tVp8n8AQ2bVKWgSvVAZrkSIB947+E=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:4U48ttccpxD/M/M6cglwZ8XGWBM= sha1:cCgkHvjrnvmsKmpCLZ9sKL2AmJI= Xref: csiph.com comp.lang.c:396291 Andrey Tarasevich writes: > On Wed 1/7/2026 8:17 AM, Andrey Tarasevich wrote: > >> which is related to how qualifications are treated under >> _Generic`. `_Generic` operates on "exact match" basis not on "type >> compatibility" basis. Which is why such matters suddenly become >> important. > > No, I take it back. `_Generic` chooses its branches based on type > compatibility. Right. For _Generic, top-level qualifiers are dropped (IIUC). Incidental comment: the discussion in DR 423 leaves much to be desired. > In that case it raises an interesting question: why does the C > standard keeps sticking to this, i.e. keeps persistent top-level > qualifiers on function parameters? Why not switch to C++-like approach > and just discard such qualifiers at the parameter type adjustment > stage? Especially now, after C17 started to explicitly do this with > the return type. My guess is that's a consequence of the processes used to write the ISO C standard and to modify the ISO C standard. A lot of work goes into both writing the text initially and revising the text later when a change is needed (talking about a change to the text, which could be either a modification of an earlier semantics or a clarification of an earlier semantics). Sometimes there is a sense that a smaller change would mean less work and also a smaller chance of unintended problems (and errors), so a smaller change is chosen even though the end result is less attractive. Perhaps that happened here, in much the same way that modifying source code might choose an easier path locally to the detriment of some larger overall aesthetic.