From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Carlo Arenas <carenas@gmail.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH 1/2] xopen: explicitly report creation failures
Date: Thu, 26 Aug 2021 09:49:27 -0700 [thread overview]
Message-ID: <xmqqa6l4f8x4.fsf@gitster.g> (raw)
In-Reply-To: <f44bf316-efae-34ce-33e0-0161c3bb78a0@web.de> ("René Scharfe"'s message of "Thu, 26 Aug 2021 17:23:27 +0200")
René Scharfe <l.s.r@web.de> writes:
> Am 26.08.21 um 01:46 schrieb Carlo Arenas:
>> On Wed, Aug 25, 2021 at 2:11 PM René Scharfe <l.s.r@web.de> wrote:
>>>
>>> diff --git a/wrapper.c b/wrapper.c
>>> index 563ad590df..7c6586af32 100644
>>> --- a/wrapper.c
>>> +++ b/wrapper.c
>>> @@ -193,7 +193,9 @@ int xopen(const char *path, int oflag, ...)
>>> if (errno == EINTR)
>>> continue;
>>>
>>> - if ((oflag & O_RDWR) == O_RDWR)
>>> + if ((oflag & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL))
>>> + die_errno(_("unable to create '%s'"), path);
>>
>> probably over conservative, but && errno == EEXIST?
>
> No matter what error we got, if O_CREAT and O_EXCL were both given then
> we tried to create a file, so this message applies.
100% agreed.
>>> + else if ((oflag & O_RDWR) == O_RDWR)
>>> die_errno(_("could not open '%s' for reading and writing"), path);
>>> else if ((oflag & O_WRONLY) == O_WRONLY)
>>> die_errno(_("could not open '%s' for writing"), path);
>>
>> Since you are already changing this code, why not take the opportunity
>> to refactor it
>> and remove the " == FLAG" part of these conditionals which is
>> otherwise redundant?
>
> The repetition is unsightly, but it's a different issue that should be
> addressed separately. Simply removing the comparison feels iffy,
> though. POSIX doesn't seem to forbid e.g. O_RDONLY to be 1, O_WRONLY
> to be 2 and O_RDWR to be 3, and then you need to check all masked bits.
> I can't think of simpler alternative to the comparison.
I fully agree that such a change, if done, must be done in an
unrelated patch.
It is funny that the code is already prepared for such a case where
RDWR is defined as RDONLY|WRONLY. I wonder if we wrote the series
of comparisons in this order on purpose, or we were just lucky, when
we did 3ff53df7 (wrapper: implement xopen(), 2015-08-04) ;-)
>
>> Either way "Reviewed-by", and indeed a nice cleanup.
>
> Thank you!
Yes, indeed, this is nicely done.
prev parent reply other threads:[~2021-08-26 16:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 20:14 [PATCH 1/2] xopen: explicitly report creation failures René Scharfe
2021-08-25 20:16 ` [PATCH 2/2] use xopen() to handle fatal open(2) failures René Scharfe
2021-08-25 23:46 ` [PATCH 1/2] xopen: explicitly report creation failures Carlo Arenas
2021-08-26 15:23 ` René Scharfe
2021-08-26 16:49 ` Junio C Hamano [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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa6l4f8x4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=carenas@gmail.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
/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 NNTP newsgroup(s).