Re: [RFA] Integrated hashtables take 2

[Mark Mitchell <mark at codesourcery dot com>]

    /* Takes up space of tree_common.  */
    struct
    {
      PTR chain;
      PTR type;
      char code_and_flags[4];
    } ignore;

I'd rather this was something the client could configure in some way.
Anyhow, I just do:

  PTR data1;
  PTR data2;
  char data3[4];

to make it clear that cpplib doesn't use these fields in any way.

I'm not 100% sure this will work with (say) a 64-bit host.  Will we
get the right alignment for the next field?

I think my idea of "negative inheritance" where cpplib would
internally manipulate data by getting a pointer to the middle of the
object, and then the front-ends would subtract a few bytes to get a
proper tree_identifier is a little cleaner still.

Am I making sense?

  I'll put an enable-checking-only run-time check in the C front end
  that offset_of (rid_code) matches between the two, similarly for len
  and name, and that sizeof (cpp_hashnode) == sizeof
  (c_common_identifier).  That should be enough.

I wouldn't even bother with the ENABLE_CHECKING.  This will be a cheap
check done once, and failure is a total catastrophe, so we may as well
just always do it.

  We can try to save more space from the "tree_common" in a later patch,
  but I don't want to do too much at once.

Agreed.

  Besides, I have a plan to start to virtualize trees I'd like to put to
  you.

Neat.

Thanks,

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