>  You actually get an x86 instructions for a 'syscall':

I can't reproduce that: https://godbolt.org/z/55hvM4xKx
How do you get it to inline printf?

On Tue, Mar 14, 2023 at 10:10 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Mon, Mar 13, 2023 at 6:51 PM Thiago Macieira via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
> Your investigation is wrong. On POSIX systems, writing to stdout will cause a
> write() to STDOUT_FILENO, which is 1. That's required.


I thought if I provided a definition for "write", then it would have
an effect for printf, puts, cout, cerr, and so on. But it doesn't.

It doesn't because even if you link dynamically with the Standard C
library on a Linux GNU compiler (i.e. glibc), you still get some
inline assembler in your executable file. That is to say, 'printf'
doesn't invoke 'write'.

Where you would expect to see something like the following assembler
for 'printf':
       mov rdi, 1
       mov rsi, "hello!!"
       mov rdx, 7
      call write@plt

You actually get an x86 instructions for a 'syscall':
       mov al, 1
       add di, 1
       mov rsi, "hello!!"
       push rsi
       mov rsi, rsp
       mov dl, 7
       syscall

I think the "1" for stdout isn't hardcoded though -- it must be gotten
at runtime from something like "stdout->_fileno".

In my original post I listed three ways in which I was redirecting
output. All three are necessary -- I can't remove any of them.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals