[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240507000135.GF5341@brightrain.aerifal.cx>
Date: Mon, 6 May 2024 20:01:35 -0400
From: Rich Felker <dalias@...c.org>
To: Tony Ambardar <tony.ambardar@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2] add renameat2 linux syscall wrapper
On Mon, May 06, 2024 at 04:42:10PM -0700, Tony Ambardar wrote:
> On Mon, May 06, 2024 at 10:50:57AM -0400, Rich Felker wrote:
> > On Tue, Apr 23, 2024 at 04:43:55PM -0700, Tony Ambardar wrote:
> > > This syscall is available since Linux 3.15 and also implemented in glibc
> > > from version 2.28. It is commonly used in filesystem or security contexts.
> > >
>
> [SNIP]
>
> >
> > If flags is 0, the SYS_renameat syscall is semantically equivalent to
> > the SYS_renameat2 one, so it would be better to just unconditionally
> > do that first rather than failing and falling back.
> >
>
> Do you mean rearranging and dropping the ENOSYS conditional, e.g. something
> like below?
>
> > int r;
> > #ifdef SYS_renameat
> > if (!flags) r = __syscall(SYS_renameat, oldfd, old, newfd, new);
> > else
> > #endif
> > r = __syscall(SYS_renameat2, oldfd, old, newfd, new, flags);
> > return __syscall_ret(r);
>
> Please clarify and I'll update.
>
> Thanks,
> Tony
Yes, or just (simpler, without any "int r;"):
if (!flags) return syscall(SYS_renameat, ...);
etc. The use of __syscall and manually calling __syscall_ret is only
helpful if you want to peek/poke at error codes prior to setting errno
and returning.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
