All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] tools/nolibc: simplify mode handling in open() and openat()
Date: Mon, 27 Apr 2026 19:47:51 +0200	[thread overview]
Message-ID: <ae-hR8DMk5fOyBwl@1wt.eu> (raw)
In-Reply-To: <c78b3af1-448d-4468-a88a-55c489f5f33c@t-8ch.de>

Hi Thomas!

On Mon, Apr 27, 2026 at 07:28:22PM +0200, Thomas Weißschuh wrote:
> On 2026-04-19 22:16:01+0200, Thomas Weißschuh wrote:
> > On 2026-04-19 18:08:07+0200, Willy Tarreau wrote:
> > > On Sun, Apr 19, 2026 at 05:29:05PM +0200, Thomas Weißschuh wrote:
> > > The macro passes the "mode" argument to _open() when it's present, and when
> > > it's absent, it passes the next one in the _OPT_ARG() macro, which is zero.
> > > 
> > > E.g.:
> > > 
> > >   #include <stdio.h>
> > >   
> > >   #define _OPT_ARG(a0, a1, ...) a1
> > >   #define open(path, flags, mode...) _open(path, flags, _OPT_ARG(0, ##mode, 0))
> > >   
> > >   int _open(const char *path, int flags, int mode)
> > >   {
> > >      return printf("path=%s flags=%d mode=%d\n", path, flags, mode);
> > >   }
> > 
> > This is exactly what I tried to do. But ,## only works for the
> > non-first argument and I didn't think of adding a dummy argument, so I
> > ended up with __VA_OPT__.
> > 
> > As open() is defined to be a function, I used the same name for both the
> > vararg macro and the underlying function. I slightly prefer that, but if
> > you object, let's rename it to _open().
> > 
> > >   int main(void)
> > >   {
> > >           open("file1", 12);
> > >           open("file2", 34, 56);
> > >           return 0;
> > >   }
> > > 
> > >   $ ./a.out
> > >   path=file1 flags=12 mode=0
> > >   path=file2 flags=34 mode=56
> > > 
> > > And this one works even on very old compilers (gcc-3.4 successfully tested).
> > 
> > Let's use that.
> 
> Sashiko rightfully complains[0] that '#define open()' will also apply to
> struct member functions called open(). So I'm holding off on this patch
> for now.

Ah indeed, that's a good point, I hadn't thought about these ones. And
yes, this can easily happen.

Willy

      reply	other threads:[~2026-04-27 17:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19 15:29 [PATCH 0/3] tools/nolibc: open() cleanups Thomas Weißschuh
2026-04-19 15:29 ` [PATCH 1/3] selftests/nolibc: drop unnecessary 'mode' argument to open() Thomas Weißschuh
2026-04-19 15:33   ` Willy Tarreau
2026-04-19 15:29 ` [PATCH 2/3] tools/nolibc: add creat() Thomas Weißschuh
2026-04-19 16:08   ` Willy Tarreau
2026-04-19 15:29 ` [PATCH 3/3] tools/nolibc: simplify mode handling in open() and openat() Thomas Weißschuh
2026-04-19 16:08   ` Willy Tarreau
2026-04-19 20:16     ` Thomas Weißschuh
2026-04-27 17:28       ` Thomas Weißschuh
2026-04-27 17:47         ` Willy Tarreau [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=ae-hR8DMk5fOyBwl@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.