Date: Tue, 14 Mar 2023 10:31:05 -0300
> 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_at_[hidden]> wrote:
> On Mon, Mar 13, 2023 at 6:51 PM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> 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_at_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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
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_at_[hidden]> wrote:
> On Mon, Mar 13, 2023 at 6:51 PM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> 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_at_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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-03-14 13:31:21