World: r4wp

I'm assuming that 'append-string copies the source parameter.  Right?

Yes, it needs to for appending. It's not a linked list of strings 
or something like that

OK.  The mental picture grows clearer.

So file2 is unneeded in there, because appending the literal copies 
it, anyway

It's a contiguous memory area, just like a block in REBOL

OK.

append-string returns the result, so you can chain them just like 
in REBOL

append-string append-string file1 "dir/" "file.txt"

If 'file1 is initialized but hasn't been assigned a value, can append-string 
use it as the target?

How do you mean? Initialising means assigning a value

What I mean is this:

file1: make-c-string 128
append-string append-string file1 "dir/" "file.txt"

But you did assign a value there: a memory block of 128 bytes

The only problem with using it as a target is that it may not be 
initialised as an empty string. For that, it needs to hold a null 
byte marker

In my tests, it did not work.  How do I initialize it with a null 
byte marker?  Like this?

file1: make-c-string 128
file1: #"^(00)"
append-string append-string file1 "dir/" "file.txt"

file1/1: #"^(00)"

There is also a pre-defined constant "null-byte" available:

file1/1: null-byte

Oh no!  Just found a bug in the Linux-ARM version of Red/System. 
 It has to do with string handling, but I haven't isolated yet.  
Will post here once I do.

If you're lucky, it may be fixed in the dyn-lib-emitter branch

It appears to have something to do with pointers and 'append-string.

Consider the following code snippet:

	print-line file1
	append-string file1 "/img00.bin"
	print-line file1

On Windows, it outputs:

	to-process/2013-06-29-20-18-55.h264
	to-process/2013-06-29-20-18-55.h264/img00.bin

The exact same code on Linux-ARM outputs:

	to-process/2013-06-29-20-19-06.h264
	/img00.bin/2013-06-29-20-19-06.h264

Odd. The append somehow considers the string empty on ARM, but it 
doesn't close the appended part with a null byte, either

That's what I was thinking.

Could you print the string lengths, as well?

How does one do that?

length? file1

That's too much like Rebol.

We could distort it :-)

The append is done by the C library, so if it doesn't append a null 
byte, that would explain it

OK.  That's just weird.  With the following code snippet:

	print-line [file1 " " length? file1]
	append-string file1 "/img00.bin"
	print-line [file1 " " length? file1]

We get these results on Linux-ARM:

	 36process/2013-06-29-20-18-55.h264
	/img00.bin 4613-06-29-20-18-55.h264

It looks like the problem is happening before the 'append-string.

Here is a more complete snippet ending with what I posted above:

	file1: make-c-string 128
	copy-string file1 "to-process/"
	append-string file1 first-line

	file3: make-c-string 128
	copy-string file3 file1

	print-line [file1 " " length? file1]
	append-string file1 "/img00.bin"
	print-line [file1 " " length? file1]

The above works perfectly on Windows.

Did you update the binding yet? I've reversed the argument order 
of COPY

No

With the updated ANSI.reds, I get the following error when compiling 
now:


*** Compilation Error: argument type mismatch on calling: copy-string
*** expected: [integer!], found: [c-string!]
*** in file: %motion-detect.reds
*** at line: 47
*** near: [
    append-string file1 first-line
    file3: as c-string! allocate 128
]

Sorry, messed that up

Fixed it

Now I get this beautiful output:

¢÷¶¢÷¶ÿÿÿÿð£÷¶ð£÷¶ 20
¢÷¶¢÷¶ÿÿÿÿð£÷¶ð£÷¶/img00.bin 30

¢÷¶¢÷¶/img00out.bin

*** Runtime Error 1: access violation
*** at: B6EC5C0Ch

I must be doing something wrong...

At least the lengths are showing up in the right place...

It seems that the 36 is one too high. Does it also print that on 
Windows?

Here's Windows:

¢÷¶¢÷¶ÿÿÿÿð£÷¶ð£÷¶ 20
¢÷¶¢÷¶ÿÿÿÿð£÷¶ð£÷¶/img00.bin 30

¢÷¶¢÷¶/img00out.bin

*** Runtime Error 1: access violation
*** at: B6EC5C0Ch

Sorry, here's Windows:

+?3+?3 6
+?3+?3/img00.bin 16
x?3
8?3/img00out.bin

*** Runtime Error 1: access violation
*** at: 77C47AB4h

Did you reverse copy-string file3 file1 ?

No.  That would probably be important.

But with it reversed, it looks strange.  It's the opposite of the 
order of 'append-string, 'find-string and all those other operations 
now.

Do I also reverse 'copy-string-part?

Yes, I think it's a more natural order. You copy or move from to

Here on Intel Linux I get:

to-process/2013-06-29-20-18-55.h264 35
to-process/2013-06-29-20-18-55.h264/img00.bin 45

Without the reversal, you were overwriting file1 with random memory 
from file3