Re: Article by Simon Tatham about Flaw in _Generic

Path	csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From	Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups	comp.std.c
Subject	Re: Article by Simon Tatham about Flaw in _Generic
Date	Mon, 31 Jul 2023 17:40:26 -0000 (UTC)
Organization	A noiseless patient Spider
Lines	53
Message-ID	<20230731103604.125@kylheku.com> (permalink)
References	<20230730135125.994@kylheku.com>
Injection-Date	Mon, 31 Jul 2023 17:40:26 -0000 (UTC)
Injection-Info	dont-email.me; posting-host="db4e7d5525dd2ff2477b6d7afaeaf07f"; logging-data="3512909"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zwV1Ucd0+UFVkJz7SPq7cUx4t2VTBGuU="
User-Agent	slrn/1.0.3 (Linux)
Cancel-Lock	sha1:wQF7FnEbwzPpRy9eBju9UsC5fwQ=
Xref	csiph.com comp.std.c:6523

Show key headers only | View raw

On 2023-07-30, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/c11-generic/
>
> In spite of _Generic being a compile-time type switch, the unused
> clauses all have to type check with a given argument.
>
> E.g. any of the cases maps an argument x to (x)->memb, then
> the argument cannot be a "char *".
>
> _Generic should only require that the clauses parse, using
> the minimal amount of type information to that aim,.
>
> (If the clauses don't parse, they cannot be identified,
> so the construct cannot work. When sscanning the association
> list, when the implementation encounters a nonmatching type,
> it has to parse the associatead expression in order to find
> the next clause in the association list.)
>
> I would havce designed this with required parentheses:
>
>   _Generic(expr, t1: (e1), t2: (e2), ... :default (edfl));
>
> Only the matching expression would be fully parsed; the non-matching
> ones would be regarded as token sequences in which parentheses and
> braces have to balance.

Another idea is to parse and type check each of the en, but inside each
one, pretend that expr has the type of tn.

We invent a generated symbol __g0025 and transform
the construct like this. Here I'm using GCC brace expression
syntax ({ ... }):

  _Generic(expr,
          t1 : ({t1 __g0025 = expr; ee1; }),
          t2 : ({t2 __g0025 = expr; ee2; }),
          // ...)

Here ee2 denotes e1, but with __g0025 substituted for
expr (so that expr is evaluated only once).

Under this transformation, the ony type error we have
in the dead clauses occurs in the initialization of
__g0025 which isn't compatible with tn on the left.

The implementation can arrange to suppress that
diagnostic, and then just parse and type-check ee2, which has a
correctly typed __g0025 in scope.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Article by Simon Tatham about Flaw in _Generic Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-30 21:39 +0000
  Re: Article by Simon Tatham about Flaw in _Generic Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-31 17:40 +0000
    Re: Article by Simon Tatham about Flaw in _Generic Martin Uecker <ma.uecker@gmail.com> - 2023-08-01 23:35 -0700

csiph-web