On Fri, May 01, 2009 at 08:23:08PM -0700, Ben Pfaff wrote:
John Darrington <[email protected]> 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. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature
_______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
