[PATCH v3 02/29] Prepare for the addition of the <sys/pagesize.h> header

[Maciej W. Rozycki]

On Tue, 1 Oct 2024, Paul Eggert wrote:

> >   And why is it going to be a problem?
> 
> It's in a standard as a constraint, which means standard compilers are
> required to issue a diagnostic, unfortunately.

 Thank you, Captain Obvious.

> > The ISO C24 clause you refer says:
> 
> Oops, I meant to cite paragraph 3 not paragraph 2. Sorry about that. Paragraph
> 3 says, "An inline definition of a function with external linkage shall not
> ... contain, anywhere in the tokens making up the function definition, a
> reference to an identifier with internal linkage." This means a user-defined
> extern inline function cannot call a static function.

 Is it a correct interpretation though that this applies to static inline 
function definitions?  Those definitions have always been a type-checked 
equivalent to macros and to make them cause a compilation warning as from 
ISO C24 seems counter-productive (with "always" as in "for 20+ years").

 Needless to say GCC doesn't issue any diagnostics for this program:

static inline int
bar (void)
{
  return 0;
}

extern inline int
foo (void)
{
  return bar ();
}

int
main (void)
{
  return foo ();
}

-- not even at `-Wall -W -pedantic -std=iso9899:2024' (and regardless of 
optimisation or the lack of requested).

> I suppose we could do something like this:
> 
>   #if __GNUC_PREREQ (3,2) || __glibc_has_attribute (__always_inline__)
>   static __always_inline long int
>   __glibc_sysconf (int __name)
>   {
>     ... optimizations go here ...
>   }
>   # define sysconf(name) __glibc_sysconf (name)
>   #endif
> 
> This would support the C standard rules, so long as GCC is smart enough to not
> issue a diagnostic about this sort of thing (is it?).

 This is a definition of a static inline function, the calling of which 
you just told me is not supported from extern inline functions as from ISO 
C24, so I'm even more confused now.

  Maciej