From: Mathias Hasselmann <mathias.hasselmann@gmx.de>
To: Josh Triplett <josht@linux.vnet.ibm.com>
Cc: Rob Taylor <rob.taylor@codethink.co.uk>, linux-sparse@vger.kernel.org
Subject: Re: GObject introspection patches
Date: Thu, 06 Sep 2007 00:42:04 +0200 [thread overview]
Message-ID: <1189032124.6389.20.camel@localhost> (raw)
In-Reply-To: <1189024611.16411.11.camel@josh-work.beaverton.ibm.com>
[-- Attachment #1.1: Type: text/plain, Size: 3137 bytes --]
Rob and Josh, thank you for review. Attaching more patches.
Am Mittwoch, den 05.09.2007, 13:36 -0700 schrieb Josh Triplett:
> Thanks for reviewing these, Rob. Further comments below.
>
> > > From 98fae4f8d2d1f375a18aeaf1e0a0c71107fbeba8 Mon Sep 17 00:00:00 2001
> > > From: Mathias Hasselmann <mathias.hasselmann@gmx.de>
> > > Date: Tue, 4 Sep 2007 22:26:47 +0200
> > > Subject: [PATCH] Introduce attribute structure for storing custom attributes in symbol nodes.
>
> Looks reasonable to me too; I wonder if this generalization could cover
> some other things like contexts, particularly with appropriate
> factored-out functions to combine attributes from symbols.
Seems that I do not know Sparse well enough yet to understand
which chance for refactoring you see.
> > > Subject: [PATCH] c2xml: Add support for custom attributes and omit end position information when
> > > equal to start position. Custom attributes are needed for GObject introspection
> > > to express details like this:
> > >
> > This looks mostly fine, though I'm not sure about defining
> > attribute_table inside c2xml. Either these are generally useful and so
> > should be in (say) sparse.c, or they're specific to
> > Gobject-introspection, and so there should be a way of providing them as
> > input to c2xml, perhaps defined in an input xml document, and
> > namespacing them in the output appropriately?
Having definitions for GObject specific attributes within an external
file seems reasonable for me: No need to patch sparse everytime we GNOME
guys invent a new attribute for our code. But instead of using XML for
that external definition I feel like using Sparse's builtin tokenizer.
> At a minimum, Sparse should know about these attributes in order to
> ignore them. In theory, Sparse should ignore any attributes it doesn't
> know about, like GCC's -Wno-attributes, but that seems error-prone.
> Alternatively, we could introduce some new builtin for testing for
> available attributes; feature testing seems better than version testing,
> and Sparse does develop new features over time, so that might help for
> new Sparse features as well. That would allow something like
> conditional compilation based on individual attributes:
> #if defined(__CHECKER__) && __attribute_exists__(element_type)
> #define element_type(x) __attribute__((element_type(x)))
> #endif
Agreed. This __attribute_exists__ builtin looks like a pretty idea.
Guess we also should convince the gcc hackers to introduce it.
> > > Subject: [PATCH] c2xml: Implement command line options:
>
> Just to clarify something: feel free to refactor Sparse's command-line
> handling itself, which I think needs some work to make it usable by
> anything other than the sparse backend.
Attached there is a new variant of the patch, playing nice with Sparse's
command-line parse. Concept is borrowed from glib's GOptionContext. Upon
approval I'll modify Sparse's command line parser to use this extensible
infrastructure.
Ciao,
Mathias
--
Mathias Hasselmann <mathias.hasselmann@gmx.de>
http://taschenorakel.de/
[-- Attachment #1.2: 0001-parse.dtd-Fix-errors-in-definition-of-the-symbol-el.patch --]
[-- Type: application/mbox, Size: 2145 bytes --]
[-- Attachment #1.3: 0002-c2xml-Output-argument-and-expansion-nodes-for-macro.patch --]
[-- Type: application/mbox, Size: 4459 bytes --]
[-- Attachment #1.4: 0003-c2xml-Implement-support-for-command-line-options-b.patch --]
[-- Type: application/mbox, Size: 6255 bytes --]
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-05 22:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 21:08 GObject introspection patches Mathias Hasselmann
2007-09-05 19:21 ` Rob Taylor
2007-09-05 20:36 ` Josh Triplett
2007-09-05 22:42 ` Mathias Hasselmann [this message]
2007-09-07 20:48 ` Mathias Hasselmann
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=1189032124.6389.20.camel@localhost \
--to=mathias.hasselmann@gmx.de \
--cc=josht@linux.vnet.ibm.com \
--cc=linux-sparse@vger.kernel.org \
--cc=rob.taylor@codethink.co.uk \
/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.