From: Tobias Bading <tbading@web.de>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-help@sourceware.org, Godmar Back <godmar@gmail.com>
Subject: Re: (stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!??
Date: Mon, 15 Feb 2021 11:02:16 +0100 [thread overview]
Message-ID: <bb5d454f-f716-5049-b213-99d6117c0a56@web.de> (raw)
In-Reply-To: <878s7pfyvc.fsf@oldenburg.str.redhat.com>
> Yes, this is not a POSIX conformance issue.
o.O
I don't get it. How is a developer supposed to decide in which cases
EINTR handling is required? Check the man page on every platform the
code is supposed to work on and hope that at least one platform mentions
EINTR if the function is indeed able to fail that way?
Tobias
---
On 15.02.21 10:45, Florian Weimer wrote:
> * Tobias Bading:
>
>>> Returning EINTR in stat would allow relatively straightforward
>>> implementation of a timeout, in case the path resides on a network file
>>> system and the server is unreachable. So it's not a completely
>>> unreasonable thing to do.
>> Good point.
>>
>>> On the other hand, the cost in lost backwards
>>> compatibility with applications that do not know about this behavior
>>> appears to be pretty high, as this thread shows.
>> What's your interpretation of the POSIX standard? Does it permit such a
>> backwards compatibility breaking change?
> Yes, this is not a POSIX conformance issue. POSIX also does not make
> any requirements regarding backwards compatibility or bug-for-bug
> compatibility.
>
> Thanks,
> Florian
next prev parent reply other threads:[~2021-02-15 10:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-14 11:13 Tobias Bading
2021-02-14 12:18 ` Tobias Bading
2021-02-14 13:17 ` Tobias Bading
2021-02-14 15:14 ` Godmar Back
2021-02-14 15:20 ` Godmar Back
2021-02-14 17:30 ` Tobias Bading
2021-02-14 22:04 ` Godmar Back
2021-02-15 9:15 ` Tobias Bading
2021-02-15 9:24 ` Florian Weimer
2021-02-15 9:43 ` Tobias Bading
2021-02-15 9:45 ` Florian Weimer
2021-02-15 10:02 ` Tobias Bading [this message]
2021-02-15 10:20 ` Florian Weimer
2021-02-15 10:36 ` Tobias Bading
2021-02-15 8:33 ` Tobias Bading
2021-02-15 8:45 ` Konstantin Kharlamov
2021-02-15 10:25 ` Tobias Bading
2021-02-14 17:56 ` Konstantin Kharlamov
2021-02-14 18:58 ` Tobias Bading
2021-02-14 20:46 ` Konstantin Kharlamov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb5d454f-f716-5049-b213-99d6117c0a56@web.de \
--to=tbading@web.de \
--cc=fweimer@redhat.com \
--cc=godmar@gmail.com \
--cc=libc-help@sourceware.org \
/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).