Re: [RFA] Integrated hashtables take 2

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Neil" == Neil Booth <neil@daikokuya.demon.co.uk> writes:

    Neil> Would this work?  cpplib and the front ends are sharing some
    Neil> of the data too: the name and length.  So we'd be muxing up
    Neil> structures whatever we do.

I think I'm not being concrete enough.  Here's a more concrete sketch:

  struct cpp_id {
    const char *name;
    int length;

    macro_info mi;
    other_stuff os;
  };

All functions in CPP manipulate `cpp_id *' -- except those that
actually allocate a cpp_id:

  cpp_id *new_cpp_id () {
    /* PADDING is configurable by the client, and set by
       cpp_set_padding at startup.  It defaults to zero.  */
    void* data = malloc (sizeof (struct cpp_id) + padding);
    return (cpp_id *) ((char *) data + padding)
  }

At this point, certainly cpplib is happy.  Everything's just peachy --
it doesn't care that there's some extra stuff at the beginning that it
never sees.

Here's what `struct tree_identifier' should be:

  struct tree_identifier {
    tree_common common;
    cpp_id id;
  };

  #define IDENTIFIER_POINTER(NODE) \
    (IDENTIFIER_NODE_CHECK (NODE)->identifier.id.name)
  #define IDENTIFIER_LENGTH(NODE) \
    (IDENTIFIER_NODE_CHECK (NODE)->identifier.id.length)

Now, over in front-end land, during initialization:

  /* Tell CPP how much extra data we need.  */
  cpp_set_padding (offsetof (id, tree_identifier));

This will work out no matter what the alignment requirements are, I
think.

Now in front-end land, when wanting a tree_identifier:

  tree id = (tree) cpp_hashtable_lookup (name);

That "just works" because we've allocated the extra space at the
beginning.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com