implement reinterpret using jl_reshape_array

[StefanKarpinski]

This should as a side-effect allow the result array to share memory with the argument array.

[JeffBezanson]

Here's a non-obvious issue: I currently allocate all byte arrays with a hidden extra 0 at the end so they can be passed to C as strings without worrying about it. If an array is reinterpreted in place to a byte array, that 0 won't be there.

[StefanKarpinski]

Good call. That would certainly be a subtle nasty bug at some point. Two possibly options I can think of:

• put a zero byte at the end of all arrays
• only add the zero byte when the array is made part of a ByteString object

For the latter, the way that makes the most sense to me is that when an array of bytes is "given" to a byte string (ASCII or UTF-8) we grow the array by one byte which is set to zero and then the length of the string object is one less than its data buffer. This has the advantage of not adding extra overhead to all byte arrays and being far less magical than what we have now.

[StefanKarpinski]

The downside, of course is that it doesn't address actual Array{Uint8} objects.

[StefanKarpinski]

This would actually be breaking since it changes the semantics of reinterpret. Idea: maybe we should have reshape! and reinterpret! as the memory-sharing versions and have reshape and reinterpret as the copying versions. The above issues with reinterpret still exist.

[JeffBezanson]

I think it's pretty important NOT to name this reinterpret!, because code that uses it can still be purely functional. Same with reshape of course.

[StefanKarpinski]

How should we handle the trailing NUL thing?

[JeffBezanson]

We should probably just put a zero at the end of all arrays, that's simplest.

[JeffBezanson]

Ok, I'm changing my mind now. That extra byte will require an extra word, which is really not ok for small arrays. Plus, reinterpreting a non-byte array to a byte array and then using it as a string is an extremely strange thing to do. Indeed I can't think of a single use case for that. We might just have to document that only arrays originally allocated as byte arrays have the extra 0.