__REDIRECT macro

[Zack Weinberg]

On Mon, Oct 28, 2024, at 5:19 AM, Martin Uecker wrote:
> Am Montag, dem 28.10.2024 um 08:33 +0100 schrieb Florian Weimer:
>> I don't know if that's what prompted Zack to make his 1998 change,
>> you would have to ask him that.
>
> Now CC-ed.

It has been a very long time but I believe the primary motivation was
C (not C++) standard compliance.  The C standard permits any standard
library function to be defined as a *function-like* macro, but not as an
object-like macro (7.1.4p1).  But a function-like macro cannot be used
to intercept all uses of the function name, so some other mechanism was
needed.  There may have been other concerns at the time, this is just
the one I remember.

> The background for my inquiry is a proposal ("Transparent Aliases" *)
> for WG14 that would allow
>
> void bar(void); _Alias foo = bar;
>
> which - according to my understanding - would correspond to
>
> void foo(void) __asm("bar");
>
> This seems to be sufficient for __REDIRECT, but would not support
> other use cases of __asm (e.g. assembler names that are not C
> identifiers or mapping to functions not declared before in the same
> TU etc.)

Look carefully at how glibc does symbol versioning; IIRC that does
involve use of __asm with assembler names that are not C identifiers.
Also, there may be cases where glibc uses __REDIRECT to map onto a
function with a different prototype, although I wouldn't blame the C
committee for refusing to support that.

zw