Re: outb(2): terminology correction

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Sep 11, 2026, at 13:36, Alejandro Colomar wrote:
>> Date: 2026-08-31 09:09:46+0000
>> From: astian <astian@memeware.net>

> Yes, 'inline functions' seems more appropriate than 'inline macros' (all
> macros are inlined, due to how the preprocessor works, so they'd be just
> macros, and as you showed, these are not even macros --except maybe in
> some architectures--).
>
> However, I doubt the entire paragraph.  I don't know why inline
> functions would produce unresolved references at link time _even if they
> were not substituted_.  The point of inline functions is that they are
> sometimes inlined, and sometimes not, and the compiler does the right
> thing in both cases.
>
> This seems like paranoia from decades ago, when inline functions were
> less known (and maybe compilers were more buggy than they are now).

My best guess is that this described a bug in glibc that was fixed in
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=994cc0ea88ce7a33d532b735c0723705742b1a7e

commit 994cc0ea88ce7a33d532b735c0723705742b1a7e
Author: Andreas Jaeger <aj@suse.de>
Date:   Wed Aug 23 16:57:31 2000 +0000

    (_EXTERN_INLINE): Remove. Use static __inline instead of _EXTERN_INLINE.

--- a/sysdeps/unix/sysv/linux/i386/sys/io.h
+++ b/sysdeps/unix/sysv/linux/i386/sys/io.h
@@ -40,12 +40,7 @@ extern int iopl (int __level) __THROW;
 
 #if defined __GNUC__ && __GNUC__ >= 2
 
-# ifndef _EXTERN_INLINE
-#  define _EXTERN_INLINE extern __inline
-# endif
-
-
-_EXTERN_INLINE unsigned char
+static __inline unsigned char
 inb (unsigned short int port)
 {
   unsigned char _v;
...

Using 'extern __inline' without optimization in --std=gnu89 would lead to
the compiler using an 'extern' reference rather than emitting a static
version, the 'static __inline' variant works as intended in both gnu
and standard c99.

> Arnd, should we remove the paragraph entirely?  Or is there any obscure
> reason why optimizations are required?

Yes, removing it seems best to me. If you're changing the file, I would
suggest also adding a note that the interfaces are nonportable and only
work on x86 and alpha. 32-bit arm has an empty stub implementation for
sys/io.h, everything else doesn't seem to have anything in glibc here.

       Arnd