World: r4wp

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

Yes, I can see that now.

Works fine on Windows again, but on Linux-ARM I'm still getting messed 
up:

	 36process/2013-06-29-20-19-37.h264
	/img00.bin 4613-06-29-20-19-37.h264

Everything points to null endings lacking

Is that on Arch Linux?

No, I'm using Raspbian Wheezy right now.

Odd, that's probably just the GNU C library

Based on Debian, so probably.

Try adding an explicit null marker after each append

OK.  Currently 42C (108F) outside my house.  My small window air 
conditioner can't keep up.  My fingers are slipping on the keys.

Wow, my hard disk runs that hot

It was 44C today but it is starting to cool off.

My official C book doesn't mention null ending for strcat, but it 
does for all the other string functions, so it would be a very malevolent 
C library that doesn't implement it

Is this a good way to add that null marker?

	tmp: make-c-string 1
	append-string file1 first-line
	tmp: file1 + length? file1
	tmp/1: #"^(00)"

No, you have to ask for the length before the append, because LENGTH? 
depends on the marker

OK.

Here's my code now...still not working:

	tmp: make-c-string 1
	file1: make-c-string 128
	copy-string "to-process/" file1 ;reversed
	print-line [length? file1 " " length? first-line]
	file1len: (length? file1) + (length? first-line)
	append-string file1 first-line
	tmp: file1 + file1len
	tmp/1: #"^(00)"

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

Here's the output

	11 25
	 36process/2013-06-29-20-20-09.h264
	/img00.bin 4613-06-29-20-20-09.h264

length? is correct

Aha, that means there's an extra character at the end of your first-line

Yes.

Judging by the printing, that must be a CR

So you probably copied a Windows text file to Linux