a better way to represent values (was: Re: ADD FILES and UPDATE)

[Ben Pfaff]

Ben Pfaff <address@hidden> writes:

> The only reason is simplicity.  Code that supports numeric and
> short string data can just allocate a single "union value" for
> each data item.  That makes life so easy: you can declare a
> "union value" on the stack; you can declare an array of them and
> index easily, and so on.
>
> Code that also supports long string data has to work harder,
> because a single logical data item has to be allocated as an
> array, just to support the rare case where the data is a long
> string variable.  You then have to, usually, dynamically allocate
> each individual data item, because there's no way to predict at
> compile time how much space it will take up: it might be 8 bytes
> or 32767 bytes.  Life is harder, and it takes more care to write
> the code.
>
> So, we can "fix" this and related problems, but it's not as
> simple as just flipping a switch and allowing long string
> variables too.

Because of this issue and other related ones that have popped up
over the years, I've never really been happy with "union value".
It's a pain to have to allocate more than one of them for the
unusual case of a long string variable.

So now I want to propose a new way to do it.  Change the
definition of "union value" from this:

    /* A numeric or short string value.
       Multiple consecutive values represent a long string. */
    union value
      {
        double f;
        char s[MAX_SHORT_STRING];
      };

to this:

    /* A numeric or string value.
       Short string values are stored inline; long string values are
       dynamically allocated. */
    union value
      {
        double f;
        char short_string[MAX_SHORT_STRING];
        char *long_string;
      };

and add some helper functions to make dealing with the two
different forms of storage for strings a bit easier.

It's something of a big change, because there are a couple of
hundred of references to the `s' member of union value in the
source tree, and other related assumptions, but it will probably
make a lot of other coding easier (as we can see from this
thread).  I'm willing to do the conversion to this form myself
(and I'll even try to update the developers guide to match).

Any comments?
-- 
"Implementation details are beyond the scope of the Java virtual
 machine specification.  One should not assume that every virtual
 machine implementation contains a giant squid."
--"Mr. Bunny's Big Cup o' Java"