Fix for io_test C compilation error.

The error message being displayed by the C compiler (GCC version 4.4.1 or newer) is
meaningful.  It warns that the program is attempting to free something that is not
heap-allocated -- in this case "\n" and the definitions of other ioLiterals.

The reason why the error only appears when --fast is supplied is that aggressive inlining
brings the call to free() into the function where an ioLiteral is passed to it, so under
those circumstances the C compiler can see that something stupid is being attempted.

In the original code, the author thought is was safe to free by explicitly avoiding known
cases where the contents of a c_string was owned by another program entity.  However,
since the IO module also supplies unowned c_strings it is unsafe in general to delete
them.  I added comments liberally to the module code where c_strings are accessed, so
future programmers are warned away from this practice.

Looking forward, except where performance is a concern, strings should be used in
preference to c_strings.  The new implementation of strings will manage memory correctly,
so the programmer who uses such objects need not concern himself with ownership details.
Merge branch 'master' into fixCStrings
Merge branch 'master' into fixCStrings
Updated comments with new info from c_string interface investigation.
Merge pull request #450 from hildeth/fixCStrings

Fix for io_test C compilation error.



The error message being displayed by the C compiler (GCC version 4.4.1 or newer) is
meaningful. It warns that the program is attempting to free something that is not
heap-allocated -- in this case "\n" and the definitions of other ioLiterals.

The reason why the error only appears when --fast is supplied is that aggressive inlining
brings the call to free() into the function where an ioLiteral is passed to it, so under
those circumstances the C compiler can see that something stupid is being attempted.

In the original code, the author thought is was safe to free by explicitly avoiding known
cases where the contents of a c_string was owned by another program entity. However,
since the IO module also supplies unowned c_strings it is unsafe in general to delete
them. I added comments liberally to the module code where c_strings are accessed, so
future programmers are warned away from this practice.

Looking forward, except where performance is a concern, strings should be used in
preference to c_strings. The new implementation of strings will manage memory correctly,
so the programmer who uses such objects need not concern himself with ownership details.