All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: linux-man@vger.kernel.org, JeanHeyd Meneide <wg14@soasis.org>,
	"G. Branden Robinson" <g.branden.robinson@gmail.com>,
	Ingo Schwarze <schwarze@usta.de>
Subject: Re: [PATCH v2] _Generic.3: New page documenting _Generic()
Date: Tue, 23 Aug 2022 09:58:53 +0200	[thread overview]
Message-ID: <87mtbv4chu.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20220821115506.22850-1-alx.manpages@gmail.com> (Alejandro Colomar's message of "Sun, 21 Aug 2022 13:55:07 +0200")

* Alejandro Colomar:

> +.SH EXAMPLES
> +The following program demonstrates how to write
> +a replacement for the standard
> +.BR imaxabs (3)
> +function, which being a function can't really provide what it promises:
> +seamlessly upgrading to the widest available type.
> +.PP
> +.\" SRC BEGIN (_Generic.c)
> +.EX
> +#include <stdint.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +
> +#define my_imaxabs(j)  _Generic((intmax_t) 0,  \e
> +    int:            abs(j),                    \e
> +    long:           labs(j),                   \e
> +    long long:      llabs(j)                   \e
> + /* long long long: lllabs(j) */               \e
> +)

The macro name does not really match what the function does.  It's a
type-generic abs function, not related to the max function or intmax_t.

Note that this approach does not really work that well in practice
because macros using _Generic expand all the alternatives (in current
implementations; doing this differently requires deviating from the
layered implementation strategy suggested in the C standard).  This
means that _Generic-using macros can only be nested maybe three or four
levels deep, depending on the number of _Generic alternatives on each
level.  For <tgmath.h>, this is really not enough, so a high-quality
implementation of <tgmath.h> using _Generic is not feasible.  GCC
provides __builtin_tgmath, which is designed in such a way that when
used in a macro, the macro argument is only expanded once.

Maybe mention this under BUGS?

C++ templates do not suffer from this particular problem.

Thanks,
Florian


  reply	other threads:[~2022-08-23  7:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-20 17:10 [PATCH] _Generic.3: New page documenting _Generic() Alejandro Colomar
2022-08-21 11:55 ` [PATCH v2] " Alejandro Colomar
2022-08-23  7:58   ` Florian Weimer [this message]
2022-08-23 13:16     ` Alejandro Colomar
2022-08-23 13:24       ` Alejandro Colomar
2022-08-23 13:32     ` Alejandro Colomar
2022-08-23 13:34       ` Alejandro Colomar
2022-09-04 21:16     ` Alejandro Colomar
2022-09-04 22:06       ` Alejandro Colomar
2022-09-09 12:31       ` Alejandro Colomar

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=87mtbv4chu.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=alx.manpages@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=schwarze@usta.de \
    --cc=wg14@soasis.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 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.