[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Darrington
Subject: Re: a better way to represent values (was: Re: ADD FILES and UPDATE)
Date: Mon, 8 Dec 2008 15:34:32 +0900
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Dec 07, 2008 at 09:48:56PM -0800, Ben Pfaff wrote:
     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).

Sounds ok to me.  One of the "related assumptions" which has concerned
me, is that of character encoding.  I'm aware that there are (or at
least there were) several places where string data is copied in/out
without proper character set conversion.  Some time ago I proposed 
changing short_string to an unsigned char which would help catch these
instances.  We never got around to doing it, because the change would
have been so pervasive, but if we're going to change union value now
anyway, this would be a good opportunity to do that at the same time.


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]