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

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.

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?

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.

quoted

So I dunno. Clever, for sure, and I think it would work. I'm not sure if
the extra code merits the return or not.

Sure, why check types -- script languages get work done as well.  (I'm
fresh off a Python basics training, nice quirky language..)  But we're
in C land and static typing is supposed to help us get our operations
correct and portable.

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.

That said...

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.

-Peff