Switch CALL to use malloc/free vs OS_ALLOC/OS_FREE, simplify
Switch CALL to use malloc/free vs OS_ALLOC/OS_FREE, simplify

The routines OS_ALLOC() and OS_FREE() were originally standardized so
that when Rebol core wanted to exchange information (such as a string
or buffer) with the host--and the buffer would have to be freed by
the core or by the host--that an assumption wasn't made about what
kind of allocator would be used.

With CALL moved out of the core and into an extension, there is no
longer any communication of this nature.  CALL is a self-contained
native and so it can use whatever allocator the implementation wants.
Switching to use plain malloc() and free() corrects a current problem,
but it's likely that these allocations won't ultimately be needed
because a small fixed-size chunk buffer could be used to add data
directly to the BINARY! or STRING! outputs of CALL.

This also makes the flow of data clearer (and double checked) by
passing NULL for the pointer to the error and output buffers when
they will not be allocated by the OS_Create_Process API.  Previously
it could be difficult to tell when parameters were inputs vs. outputs.

kealist/ren-c,rgchris/ren-c,rgchris/ren-c,hostilefork/rebol,giuliolunati/ren-c,hostilefork/rebol,kealist/ren-c,hostilefork/rebol,hostilefork/rebol,draegtun/ren-c,kealist/ren-c,codebybrett/ren-c,draegtun/ren-c,codebybrett/ren-c,codebybrett/ren-c,kealist/ren-c,draegtun/ren-c,kealist/ren-c,codebybrett/ren-c,draegtun/ren-c,kealist/ren-c,hostilefork/rebol,draegtun/ren-c,codebybrett/ren-c,rgchris/ren-c,rgchris/ren-c,giuliolunati/ren-c,giuliolunati/ren-c,draegtun/ren-c,giuliolunati/ren-c,rgchris/ren-c,codebybrett/ren-c,hostilefork/rebol,giuliolunati/ren-c