World: r3wp

I'd start by printing the length of item... just to be sure its not 
the input which is the problem.

RL_Print("%d, %s", i, list[i]);

add a little newline there...

RL_Print("%d, %s\n", i, list[i]);

also make sure you ASSIGN the return value of the command, as it 
may be garbage collected otherwise.  but depending on the rebol code, 
this might not be the issue... its just good practice.

I think I found the bug.  it could have worked earlier with your 
other memory access issues but will not work anymore.
    RXA_INDEX(frm, 1) = 0;

AFAIK this effectively erases the assignment of:
    RXA_SERIES(frm, 1) = b;

darn, ignore the above. I think I'm tired... I continued searching 
the C code, and posted too quickly.

I cannot use RL_print --> undefined reference to `_imp__RL_Print'

btw.. here is my current (not working) version with (I hope all required 
files) - http://box.lebeda.ws/~hmm/temp/ext-wand.zip

I can say, that the **list is filed correctly because when I for 
example use at the tail:
            REBSER *s = RL_MAKE_STRING(strlen(list[2]), 0);
            for (c = 0;  c< strlen(list[2]); ++c)
                RL_SET_CHAR(s, c, list[2][c]);
            RXA_SERIES(frm, 1) = s;
            RXA_INDEX(frm, 1)  = 0;
            RXA_TYPE(frm, 1)   = RXT_STRING;
            return RXR_VALUE;
I get the correct list[2] value.

The problem is with the block value definition.

Ok, so simple question, how to return a block with one string inside?

using above code as reference...

RXA_SERIES(frm, 1) = b;
RXA_INDEX(frm, 1)  = 0;  // AFAIK this is 0 by default.
RXA_TYPE(frm, 1)   = RXT_BLOCK;
return RXR_VALUE;

obviously, you need to have set the first value of the block to a 
string.

And then you've got to properly construct the block in b :)

And the string?

Maxim, the setting of the string value of the block is actually my 
problem and that's why I'm asking. I can even return block with empty 
strings:) So I should extend my queastion to return block with non 
emptz string:)

https://gist.github.com/0c6305d7c25e40742b31

This contains a minimal extension that returns a block containing 
a string.

Is this working for you? Because with your code I get empty string 
inside as well.

Works for me, yes.

What hostkit do you use? A110?

yes

Ok, let me check what I use :)

A110 to run, A107 to build. Well ... :)

How can I get A107? Also you are on Linux, aren't you?

Yes, give me a minute. I'll check a full A110 on Windows.

oh.. it's too late here. I give you all day:) Thanks.

Does work for me on Linux A110, does not work for me on Win32 A110 
either.

hum... so RL_SET_VALUE has  bug in the A110 host-kit...

but RL_GET_VALUE is working fine... this is strange.

Interesting. Seems to make a difference whether I run a script which 
imports the extension or import the extension from the command line.

I had that reaction when I had an unstable CGR host-kit.

same thing, command-line would last longer before a crash, but ultimately, 
it would still fail... only further down the execution.

Same behaviour in A109. Which is actually good, as it basically rules 
out an error introduced by the struct packing changes in A110.

since my issues where related to heap memory corruption, I'd guess 
either we are using the commands improperly, the includes are not 
reflective of the actual internals, or the internals are causing 
the heap corruptions themselves.

Does not work in A107 at all, neither script nor manually.

struct packing changes?

The A110 host kit more intelligently handles struct packing.

what are the differences?

http://www.curecode.org/rebol3/ticket.rsp?id=1727

ahh those.  ok.

I'm wondering if the RL_SET_VALUE or RL_SET_CHAR  might have switched 
to using RXIARG *    instead of RXIARG  internally.

does allocating a struct/union on the stack create an implicit pointer 
(which points to the stack rather than heap) when used?

Will need more investigation. Either RL_SET_VALUE never worked, but 
I guess someone would have noticed. Or the minimal sample is missing 
something (more or less obvious).

the odbc extension uses RL_SET_VALUE IIRC.

Yes, it does.

Ah, yes. We were missing something obvious :)

Ok, confirmed that it works on both Linux and Windows A110.

A simple `a.index = 0` is missing.

ah yes... they are allocated on the stack, so memory its not cleared 
by default.

Updated the snippet accordingly:
https://gist.github.com/0c6305d7c25e40742b31

actually, in Olde's code its:   

 s.index = 0;