[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Add gcc cleanup attribute support

From: Michael Matz
Subject: Re: [Tinycc-devel] Add gcc cleanup attribute support
Date: Wed, 2 Jan 2019 19:47:56 +0100 (CET)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


On Wed, 2 Jan 2019, uso ewin wrote:

I've try to add support to cleanup attribute to TCC:

Are you interested in having this feature merge in mob ?
If yes it would be nice if someone could review my code

As you found out the one-pass nature of TCC makes implementing this somewhat awkward. Though you found some inventive solution to this I don't particularly like it, specifically:

* your use of tokens instead of a symbol ID in the cleanup attribute seems
  wasteful: in principle a cleanup is an association of a function
  (representable as its name, as ID) with a decl (a Sym), so that should
  be the only necessary thing, not the token string representing
  "func(&foo)" (when the cleanup is function "func" on decl "foo").
* your way of dealing with the "goto forward" problem is to read and
  remember all tokens after the goto until you find the label (and if so
  do the cleanups), rereading all these tokens afterwards.

  This feels ugly and against the one-pass nature (and is quadratic if you
  have very many gotos); several alternatives come to mind, though I
  haven't tried any of them to see if they result in less ugly code: e.g.
  you could remember all potentially scope-exiting gotos and check them at
  scope exit (redirecting them to the cleanup and then further to the real

I'm somewhat sympathetic to having that GCC extension, though it is one of the more arcane ones that isn't trivial to support and isn't used very often in the wild (did you have any software in mind that made you implement the extension?). So the advantage of having that extensions needs to be weighed fairly lightly against the disadvantage of complicating TCCs sources. IMHO your current implementation leans more on the disadvantage side. But maybe you can rework it somewhat along the remarks above and it turns out more elegant?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]