Am 11.08.23 um 20:24 schrieb Jeff King:

On Fri, Aug 11, 2023 at 07:59:12PM +0200, René Scharfe wrote:

quoted

quoted

we are defining an inline function with the explicit goal of passing it
as a function pointer. I don't remember all of the standard's rules
here. Are we guaranteed that it will create a linkable version if
necessary?

I don't see on which basis the compiler could refuse.  We can't expect
the function address to be the same across compilation units, but we
don't need that.  If there's a compiler that won't do it or a standards
verse that makes this dubious then I'd like to know very much.

I seem to recall some quirks where an inline function that is not called
directly is not required to be compiled at all, and the compiler can
assume that there is a definition available in another translation unit.

C99 says in 6.7.4 Function specifiers: "It is unspecified whether a call
to the function uses the inline definition or the external definition.",
referring to functions with both types of definition.  So a compiler
could ignore the inline version for those.

But I think that only applies when no storage-class specifier is
provided. In this case, you said "static", so I think it's OK?

That's how I understand it as well -- there is no external version to
choose and the compiler is not free to ignore the inline one.

It's possible I'm mis-remembering the issues, too. One problem is that
pre-C99, you might end up with the opposite problem (a compiled function
with visible linkage that conflicts with other translation units at link
time). E.g. here:

  https://stackoverflow.com/questions/51533082/clarification-over-internal-linkage-of-inline-functions-in-c/51533367#51533367

But I think with "static" we should always be OK.

*nod*

Don't get me wrong, I like type checking. It's just that doing weird
things with the language and pre-processor also carries a cost,
especially in an open source project where new folks may show up and say
"what the hell is this macro doing?". That's a friction for new
developers, even if they're comfortable with idiomatic C.

Sure, but that ship has sailed in this specific case.  Standard option
parsing would use getopt or getopt_long, neither of which has void
pointers.  We already carry the cost of our OPT_ macros.  Let's ease it.

That said...

quoted

A good example in parseopt: The patch below adds type checking to the
int options and yields 79 warning about incompatible pointers, because
enum pointers were used in integer option definitions.  The storage size
of enums depends on the member values and the compiler; an enum could be
char-sized.  When we access such a thing with an int pointer we write up
to seven bytes of garbage ... somewhere.  We better fix that.

...I do find this evidence compelling.

It's 3 instead of 7 bytes of garbage, but the point still stands..

René