On Mon, Jan 12, 2026 at 12:32:34PM +0100, Bruno Haible via Gnulib discussion list wrote: > Paul Eggert wrote: > > Bruno prefers the opposite. > > Yes, I prefer the opposite, because making use of a module is 10 times > more frequent than modifying the implementation of that module.
Something to consider, although I don't know how much overhead it would be: it might be possible to add git hooks that refuse patches to any .h or .c file where a function name appears in both but where the documentation differs between those two sites. It would mean that we could cater to a style where the documentation is placed in both locations (a redundancy) but automatically enforced (we can't get out of sync, because the attempt to commit will fail, and because it is fresh on the mind, fixing it before committing will be easier than researching after-the-fact on which of the two out-of-sync variants is intended). Of course, such a compromise requires actually developing such a tool to enforce the redundancy. But I personally would appreciate never guessing wrong on where to find the docs (since both .h and .c would have the same docs), if we move to that style everywhere. But in the meantime, I'm already used to having to guess which of two files will be interesting, and correcting my guess if it was wrong. Changing code to be consistent would be nice, but only if everyone can agree on a style; and if GNU Coding Standards does not mandate the style, it's an uphill battle bound to annoy one camp or the another, so letting things stay inconsistent is less friction. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
