From: Sergei Trofimovich <slyich@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 70411@debbugs.gnu.org, "Alejandro Colomar" <alx@kernel.org>,
"Eli Schwartz" <eschwartz93@gmail.com>,
"Pádraig Brady" <P@draigBrady.com>,
"Gnulib bugs" <bug-gnulib@gnu.org>
Subject: Re: bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin
Date: Fri, 19 Apr 2024 22:33:00 +0100 [thread overview]
Message-ID: <20240419223300.71ec1343@nz.home> (raw)
In-Reply-To: <b310a779-f58d-4915-8f3f-1f4fe9457e3f@cs.ucla.edu>
On Fri, 19 Apr 2024 00:33:52 -0700
Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 2024-04-18 14:52, Sergei Trofimovich wrote:
> > $ clang simple.c -o simple && echo 42 | ./simple
> > 1: ino=3009428657538693161
> > 2: ino=3009428657538693161
> > 3: ino=1568241705
> >
> > Note how stat() and fstat() don't agree on inode.
> >
> > Apparently it's documented in
> > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fstat.2.html
> > as
> >
> > BUGS
> > Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
> > except for the blocksize field, and a unique device and inode number.
>
> The BUGS note simply means that a pipe has a unique inode number, which
> is what we want. So that's not indicating any problem.
>
>
> Oh, I see the problem now. For a socket or pipe, macOS fstat returns
> the full 64-bit inode number, whereas macOS stat returns only the low
> order 32 bits. In your example, 3009428657538693161 % (2**32) ==
> 1568241705.
>
> This is a kernel bug in macOS. Can you report it or otherwise arrange to
> have the kernel bug fixed? I expect that you have better connections
> with Apple than I do. A proposed patch (relative to xnu-10063.101.15) is
> attached; I have not tested it as I don't use macOS. Thanks.
I reported it via https://www.apple.com/feedback/macos.html
> Also, I am documenting this macOS bug in Gnulib by installing the second
> attached patch to Gnulib, and am cc'ing this email to bug-gnulib.
Thank you, Paul!
--
Sergei
prev parent reply other threads:[~2024-04-19 21:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Zh3EDgxqkzasdBMg@debian>
[not found] ` <ee3fa9ca-7c75-2cb3-6853-ff89213036f4@draigBrady.com>
[not found] ` <20240416223758.50d36dd7@nz.home>
[not found] ` <20240418225232.21bf83cd@nz.home>
2024-04-19 7:33 ` bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin Paul Eggert
2024-04-19 21:33 ` Sergei Trofimovich [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240419223300.71ec1343@nz.home \
--to=slyich@gmail.com \
--cc=70411@debbugs.gnu.org \
--cc=P@draigBrady.com \
--cc=alx@kernel.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=eschwartz93@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).