On Tue, Apr 3, 2012 at 8:15 PM, Romain Geissler <romain.geiss...@gmail.com> wrote: > > Le 3 avr. 2012 à 18:02, David Malcolm a écrit : > >> On Tue, 2012-04-03 at 15:23 +0200, Richard Guenther wrote: >>> On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther >>> <richard.guent...@gmail.com> wrote: >>>> On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm <dmalc...@redhat.com> wrote: >>>>> I wrote a script and ported my proposed API for GCC plugins from my >>>>> CamelCase naming convention to an underscore_based_convention (and >>>>> manually fixed up things in a few places also). >>>>> >>>>> The result compiles and passes the full test suite for the Python >>>>> plugin; that said, I'm still breaking the encapsulation in quite a few >>>>> places (hey, this is an experimental prototype). >>>>> >>>>> You can see the latest version of it within the "proposed-plugin-api" >>>>> branch of the Python plugin here: >>>>> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api >>>>> >>>>> within the "proposed-plugin-api" subdirectory. >>>> >>>> Hmm, how do I get it? I did >>>> >>>> git clone http://git.fedorahosted.org/git/proposed-plugin-api >>>> >>>> but there is nothing in gcc-python-plugin/. And >>>> >>>> git checkout proposed-plugin-api >>>> >>>> says I'm already there ...? >>> >>> Meanwhile the directory magically appeared (heh ...). >> >> [The ways of git are something of a mystery to me: 95% of the time it's >> the best revision control system I've ever used, but 5% of the time the >> most obtuse] >> >>> Overall it looks good >> Thanks for taking a look. >> >>> - but it seems to leak GCC headers into the >>> plugin API (via gcc-plugin.h and input.h inclusion). Thus, it >>> lacks separating the plugin API headers from the plugin API implementation >>> headers? >> That's true. The big information "leak" happens inside >> gcc-semiprivate-types.h, which defines the various structs that act like >> pointers, each with a decl like this: >> >> struct gcc_something { >> some_private_gcc_pointer_type inner; >> }; >> >> It would be possible to make this more opaque like this: >> >> struct gcc_something { >> struct some_private_gcc_struct *inner; >> }; >> >> given that you then don't need a full definition of that inner struct >> visible to users. Though location_t is leaked, and in this approach, >> there isn't a way around that, I think. > > Well i think we you should define a public type like this : > > typedef struct some_private_gcc_struct *gcc_something; > > extern some_type retrieve_some_value(gcc_something);
Indeed. I'd go one step further and do typedef struct gcc_something_s *gcc_something; and in the implementations only expose struct some_private_gcc_struct by means of casting the pointer. For the public API gcc_something is a pointer to an opaque thing, never dereferenced. > Also, nothing should be noted public or private : all definitions > that will appear in a header installed in > $(gcc -print-file-name=plugin)/include will be public by definition. Right. Richard. > Any additional header that would be needed to implement the > API should be kept separate (like the actual *.c implementing it) > and placed in the gcc/ directory in the trunk (or better something > like gcc/plugin-impl/ to start being modular). Any definition defined > in those additional headers are private. > > Thus, you should define two sets of headers files (public and private ones), > plus body c files, and import only public header files from public header > files. > > Do you have any plan on starting integrating it to the trunk (or at least on > an > new branch on the official gcc repository) soon, like suggested by Richard ? > I might help setting up the configure/makefile and later writing some > wrappers. > (although i don't have write permission). > Cheers > > Romain Geissler
