View Issue Details

IDProjectCategoryView StatusLast Update
0000152LDMud 3.6Generalpublic2021-04-06 21:25
ReporterlarsAssigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.2.8 and before 
Fixed in Version3.6.4 
Summary0000152: replace_program() and virtual variables
DescriptionShort: replace_program() and virtual variables
From: Lars, Zonk
Date: 2003-01-19
Type: Bug
State: New

replace_program() can replace with a program only if it either doesn't
have virtually inherited variables, or is the first program inherited.

Reason is that replace_program() expects the variables of the program
in one block, starting at variable_index_offset. However, with virtual
inherites the virtually inherited variables are collected in a block
at the beginning of the variable block, so that replace_program() extracts
the wrong variables during the replacement. Only if the replaced program happens
to be the first inherited program, the variable_index_offset is 0 and
the extraction code by accident does the right thing.

The proper solution would be to use the inheritance/variable information
to extract and rebuild both virtual and nonvirtual variable blocks; however
at the moment I don't understand the structure well enough to do it.

Here are the test programs:

--- test.c ---
inherit "/test_a";
inherit "/test_c";

--- test_a.c ---
string target_program = "test_a";

--- test_c.c ---
virtual inherit "/test_b";
string var2 = "test_c";

void create()
{
  replace_program("/test_c");
  set_var("content"); call_out( "write_var", 2 );
}

--- test_b.c ---
string var;

void set_var( string value )
{ var = value; write( "object="+object_name()+" [set_var()] var="+var+"\n" ); }

public void write_var()
{ write( "object="+object_name()+" [write_var()] var="+var+"\n" ); }

------
TagsNo tags attached.

Relationships

related to 0000061 new LDMud 3.5 'use' directive to replace most uses of prototypes. 

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2004-11-26 19:31 lars New Issue
2009-10-02 02:58 zesstra Project LDMud => LDMud 3.5
2009-10-02 03:04 zesstra Relationship added related to 0000061
2014-02-10 15:18 Gnomi Assigned To => Gnomi
2014-02-10 15:18 Gnomi Status new => assigned
2021-04-06 21:24 Gnomi Project LDMud 3.5 => LDMud 3.6
2021-04-06 21:24 Gnomi Category Runtime => General
2021-04-06 21:25 Gnomi Status assigned => resolved
2021-04-06 21:25 Gnomi Resolution open => fixed
2021-04-06 21:25 Gnomi Fixed in Version => 3.6.4