[Top][All Lists]

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

Re: dict_var_resized

From: John Darrington
Subject: Re: dict_var_resized
Date: Mon, 4 May 2009 07:09:07 +0800
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, May 01, 2009 at 08:23:08PM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     > dict_var_resized exists for one purpose only -  it informs the GUI
     > that the size of a variable has changed.  That way, the var sheet 
     > always displays the correct information, even if a variable changes
     > due to some low level operation (eg: running syntax).
     Right.  So if the variable doesn't belong to a dictionary, then
     there's nothing to do.
     > Solution 2:  If that's not possible, then I think it'll be acceptable
     >     to simply test for d == NULL inside dict_var_resized and do
     >     nothing in that situation.
     > I'd prefer solution 1 if at all possible.
     I don't understand why solution 1 is preferable.  Why isn't this
     just a bug in dict_var_resized?  I note that, for example,
     dict_var_changed does test for the null-dictionary case.

Then perhaps this would be the better solution after all.

I only expressed a preference for the other solution, because  Jason's
use case is the first time that internal variables other than numeric
ones have been required.  Resizing "internal" variables seems to me
like a rather unusual thing to do, so getting a SIGSEGV is a good way
of alerting us that this unusual operation is taking place.  However,
if there is a good argument that resizing internal string variables
should be considered a commonplace operation, then I wouldn't have any
strong objections to Solution 1.

Incidently, the code I posted in my previous email was possibly
confusing because var_create_internal is supposed to take the
casereader index as its argument, not the width of the variable as I
had implied.  We'd need to create a new function in variable.c to do
what Jason wants.


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]