More fun with toStringz and the GC

[Don Allen]

Remember all the fun we had last year when I failed to heed the 
warning in the toStringz documentation about retaining a 
reference to a char * passed into C? It took a long time to find 
that one, with a lot of help from Steve Schveighoffer and others.

Well, I've got another one. Consider this:

````
         // Get number of children of the parent account
         auto gc_protect = bind_text(n_children_stmt, 1, 
parent.guid);
         parent.children.length = one_row!(int)(n_children_stmt, 
&get_int);

         auto gc_protect2 = bind_text(account_child_stmt, 1, 
parent.guid);
         for (int i = 0; next_row_available_p(account_child_stmt, 
&sqlite3_reset); i++) {
             parent.children[i] = new Account;
             parent.children[i].name = 
fromStringz(sqlite3_column_text(account_child_stmt, 0)).idup;
             parent.children[i].guid = 
fromStringz(sqlite3_column_text(account_child_stmt, 1)).idup;
             parent.children[i].flags = 
sqlite3_column_int(account_child_stmt, 2);
             parent.children[i].value = 
get_account_value(parent.children[i]);
         }
````
bind_text takes a D string, turns it into a C string with 
toStringz, uses that to call sqlite3_bind_text and returns the C 
string, which I store as you can see with the intention of 
protecting it from the gc. The code as written above does not 
work. At some point, I get an index-out-of-bounds error, because 
the loop is seeing too many children. If I turn off the GC, the 
code works correctly and the application completes normally.

With the GC on, if I put a debugging writeln inside the loop, 
right after the 'for', that prints, among other things, the value 
of gc_protect2 (I wanted to convince myself that the GC wasn't 
moving what it points to; yes, I know the documentation says the 
current GC won't do that), the problem goes away. A Heisenbug!

My theory: because gc_protect2 is never referenced, I'm guessing 
that the compiler is optimizing away the storage of the returned 
pointer, the supporting evidence being what I said in the 
previous paragraph. Anyone have a better idea?

By the way, I get the same error compiling this with dmd or ldc.

/Don Allen