[libcxx-commits] [PATCH] D98097: [libc++] "Merged wording" for D98077 and D96986

Joerg Sonnenberger via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Mar 10 13:46:57 PST 2021

joerg added inline comments.

Comment at: libcxx/include/__config:1462
+#if defined(__GNUC__) || defined(__clang__)
+#define _LIBCPP_FORMAT_PRINTF(...)                                             \
+  __attribute__((__format__(__printf__, __VA_ARGS__)))
Quuxplusone wrote:
> Mordante wrote:
> > Wouldn't it be better use 2 named arguments instead of `...`. The latter isn't officially part of C++98 and the attribute requires 3 arguments.
> I had thought I was copying style from elsewhere in this file, but I guess only `_LIBCPP_DIAGNOSE_WARNING`/`_LIBCPP_DIAGNOSE_ERROR` actually use `...` for this purpose. So the only benefit I'm getting from `...` is that I don't have to worry about naming or whitespace conventions.
> How do we feel about
> ```
> #define _LIBCPP_FORMAT_PRINTF(a, b)   \
>   __attribute__((__format__(__printf__, a, b)))
> ```
> We already use `a, b` as macro parameter names on line 227. If this naming/whitespace looks acceptable, I don't mind making this change.
> FWIW, I claim C++98-portability is not a concern, given that we already use `...` specifically in C++98 mode, e.g. in `#define static_assert(...)` on line 898.
Macro arguments are limited to the expansion as scope and disappear afterwards. They don't interact with tokens outside the macro expansion. I don't think compatibility with C++98 is a concern here, but there is no reason to give up the checking on the number of arguments here. E.g. in NetBSD they are called `fmtarg` and `firstvararg` to make it self-documenting.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list