BrianHawley/r3-bh — pull request #3 by hostilefork (2012-12-21 23:47:42+00:00)
Title: C string lits const correct (transitively), env work + SET-ENV native

*39 files???* Yup. :) Seems good to run this by you first for any improvements or insights!

In C, if you have a literal declaration like this:

char* foo = "bar";

...and then later you somehow write to or modify the data through that pointer (or an alias to it)...as you probably know...you get [undefined behavior](http://en.wikipedia.org/wiki/Undefined_behavior). It can crash, or the optimizer can juggle things so no write happens at all. All bets are off. So one should just say:

const char* foo = "bar";

I started from the top with the string literals, and kept going down the chain until I got all the compiler warnings about this to go away. Took...a while. Still, was a way of kind of browsing a lot of the code. Although lots of files were touched, the limited scope of ever really *writing* into C-style strings in the core meant it wasn't likely there'd have been a mistake. I thought I had one when I found this one in the host:

https://github.com/rebol/r3/blob/master/src/os/posix/host-readline.c#L139

...but then the [`free()`s start at index 1](https://github.com/rebol/r3/blob/master/src/os/posix/host-readline.c#L173) :P Well it's better to do the alloc and let the compiler warnings mean something than to save that one. But it's not just about protecting against errors, it also helps absorb the code faster as to what's an input and what's an output.

The real bear was it exposed weaknesses and future problems/leaks in the environment functions in the host API. Went and improved those but it clearly needs a lot of thinking about. SET-ENV/GET-ENV tested in a basic way on a MinGW on WinXP, and a 64-bit Linux...tested fallback hack on the Linux to putenv from setenv/unsetenv despite it being a complete disaster:

http://stackoverflow.com/a/5876818/211160

(It sounds like some old systems may only have that.)