World: r3wp

We're in a morass now ;-)

Think about ppl that would have complained about LENGTH? not working 
on binary! type. ;-)

No, that would not change the types of ALLOCATE and FREE, I would 
only change them to pointer! [byte!] when it will be available.

There is no generic pointer in Red/System.

Even if binary! was there, it would work as a byte! pointer.

I thought so, so ALLOCATE and FREE will still deliver types that 
I wouldn't expect from them, and that effectively introduce an extra 
definition of a variant pointer

The LENGTH? example is interesting, because people will now use it 
on an allocated binary, expecting that it's zero-terminated, and 
even if it is, the expected length will be off by one

Or much more if there's a zero somewhere in the middle

You're extrapolating from the error message. The definition says 
"byte-ptr!" not "c-string!".

Yes, that's a fundamental problem with a preprocessor

But the more tangible problem is that currently, you don't have to 
cast when you allocate a string, and that will change when a proper 
byte pointer is introduced

Right, but this is an alpha, not a v1. Maybe I should postpone the 
beta announcement by a month or two?

You don't have to, because the fix is only half a line, and I don't 
need it before Monday

Anyway, I've brought forward my concerns; that's all I can do

Well, thanks for the feedback, I will think about all the possible 
options.

OK, thanks

I see you're using byte! definitions for C functions that take integer! 
parameters. Is that guaranteed to be interpreted as an integer?

Are you referring to memset() wrapper?

Yes. What's the conversion applied there?

No conversion at all. The memset case is a old C oddity that never 
got fixed. It should have a byte in the declaration instead of int. 
The algorithm in memset uses a byte and not an int, so the Red/System 
binding is not only safe, but also cleaner than the C one. The memset 
oddity is explained there: http://stackoverflow.com/questions/5919735/why-does-memset-take-an-int-instead-of-a-char

Jocko, answering your questions:
- is this correct ?
    Yes, I tested it here, works flawlessly.

- how and where de-allocate the c-string ?

    Same as in C, when you don't need it anymore. So in your code example, 
    it would be after "print res".

- why the end-string symbol is not added automatically ?

    Red/System is a low-level language, it treats c-string! as C does 
    with string, the trailing zero is only a convention. If ReadConsole() 
    doesn't add a trailing zero, only the programmer knows if and where 
    it should be added. Red/System can only add automatically trailing 
    zero on literal c-string! because, in that case, it can easily guess 
    where the c-string! ends.

Doc, thanks for the link; that's informative

I've updated both my C library binding and my 0MQ binding to work 
with the latest Red

A lot of changes were needed, most of them for the stricter checking

Callbacks can now be passed to imported functions with fully defined 
specs. However, function specs can not be defined as the return value 
of an imported function:

on-signal: "signal" [  ; Register handlers for receiving system signals.
			signal		[integer!]
			handler		[function! [signal [integer!]]]  ; Flag or callback
;			return:		[function! [signal [integer!]]]
			return:		[handle!]
		]

Also, callbacks can't be passed as such to native functions. In some 
cases they can still be passed as unspecified handles, but those 
can't be cast to callback functions. I have a wrapper for atexit() 
that is now impossible to define:

on-quit: func [  ; Register handler for normal program termination.
;	handler		[function! []]  ; Callback
	handler		[handle!]  ; Callback
	return:		[logic!]
][
	not as-logic _on-quit handler
]

Doc, thanks for yor answers

Kaj: function! is just a pseudo-type (not a first-class type) that 
was introduced just to be able to verify callback signatures when 
passed to an external library.

I will have a look today on your issue and see if allowing function! 
to be passed as argument and returned as value is safe and side-effect 
free in the current state of the implementation.

Kaj: on Windows, it is possible to use _get_osfhandle() to retrieve 
the file handle for stdin/out/err (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx)

I can't find an equivalent in UNIX world.

I know, you have to import it as a symbol as far as I can see

Kaj: you have now a polymorphic NULL for all pointers (struct, pointer, 
c-string) and a new pointer! [byte!] type. byte-ptr! has been redefined 
to pointer! [byte!] instead of c-string!.

Is it possible to specify a build target per file? If I don't want 
to use %builds/ folder, but for example %builds/project/ and specify 
it in the project.reds file header.

Not yet, but Andreas should add it soon. Taking the output path/name 
from script header is a good idea.

Cool... I'm able to obtain image size from red using iMagick

Nice, let us know if you hit any issue.

the main issue is that I had to find out, how to print integers:) 
Kaj's C-library is not working on windows.

*** Compilation Error: multiple type casting not allowed
*** in file: %runtime/../library/C-library.reds
*** in function: temporary-name
*** at:  [as c-string! null]

here is a fix:

-- 	_temporary-name as-c-string none
++	_temporary-name none

for a real work with iMagick, the decimal numbers are required.

Kaj has not yet updated the C library binding to the latest Red/System 
version.

Float support will either be added at Red level or at Red/System 
level, depending on how the Red compiler will be built.

A bit hard to update my binding to a Red version that is released 
while I sleep, but I will have a look

By the way, my C binding was developed for Windows so far, and the 
only thing I've really used it for is printing integers :-)

I've just tested it for the the first time on Linux last night, and 
printing worked there, as well

The new pointers sound good, Doc