Re: [PATCH] describe: fix --no-exact-match

[Jeff King <peff@peff.net>]

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

> > 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.

> > 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