void[] and ubyte[]
Hi, In phobos there are places with void[] and places with ubyte[], and I can't really understand why there is this difference. I don't even see why D has a void array or void pointer anyway. For example, in std.base64, ubyte[] is used as the basic quantity for encoding, while in std.zlib, it's void[]. Both libraries have a similar pair of functions like encode/decode or compress/uncompress. Both act on raw memory. So why not use ubyte[] all the time? Isn't any stretch of bare data on the heap in the end an array of bytes? Void[] seems like a C-anachronism to me. I have no experience with void pointers or arrays, so I am probably missing something. Thanks, Stephan
Re: cast from void[] to ubyte[] in ctfe
On 13/07/12 12:52, Johannes Pfau wrote: Am Fri, 13 Jul 2012 11:53:07 +0200 schrieb Don Clugston d...@nospam.com: On 13/07/12 11:16, Johannes Pfau wrote: Casting from void[] to ubyte[] is currently not allowed in CTFE. Is there a special reason for this? I don't see how this cast can be dangerous? CTFE doesn't allow ANY form of reinterpret cast, apart from signed-unsigned. In particular, you can't do anything in CTFE which exposes endianness. It might let you cast from ubyte[] to void[] and then back to ubyte[] or byte[], but that would be all. So that's a deliberate decision and won't change? I guess it's a safety measure as the ctfe and runtime endianness could differ? Yes. Anyway, I can understand that reasoning but it also means that the new std.hash could only be used with raw ubyte[] arrays and it wouldn't be possible to generate the CRC/SHA1/MD5 etc sum of e.g. a string in ctfe. (Which might make sense for most types as the result could really differ depending on endianness, but it shouldn't matter for UTF8 strings, right?) Maybe I can special case CTFE so that at least UTF8 strings work. BTW: casting from void[][] to ubyte[][] seems to work. I guess this is only an oversight and nothing I could use as a workaround? Probably a bug. But you can convert from char[] to byte[]/ubyte[]. That's OK, it doesn't depend on endianness.
Re: cast from void[] to ubyte[] in ctfe
On 13/07/12 11:16, Johannes Pfau wrote: Casting from void[] to ubyte[] is currently not allowed in CTFE. Is there a special reason for this? I don't see how this cast can be dangerous? CTFE doesn't allow ANY form of reinterpret cast, apart from signed-unsigned. In particular, you can't do anything in CTFE which exposes endianness. It might let you cast from ubyte[] to void[] and then back to ubyte[] or byte[], but that would be all.
Re: cast from void[] to ubyte[] in ctfe
Am Fri, 13 Jul 2012 11:53:07 +0200 schrieb Don Clugston d...@nospam.com: On 13/07/12 11:16, Johannes Pfau wrote: Casting from void[] to ubyte[] is currently not allowed in CTFE. Is there a special reason for this? I don't see how this cast can be dangerous? CTFE doesn't allow ANY form of reinterpret cast, apart from signed-unsigned. In particular, you can't do anything in CTFE which exposes endianness. It might let you cast from ubyte[] to void[] and then back to ubyte[] or byte[], but that would be all. So that's a deliberate decision and won't change? I guess it's a safety measure as the ctfe and runtime endianness could differ? Anyway, I can understand that reasoning but it also means that the new std.hash could only be used with raw ubyte[] arrays and it wouldn't be possible to generate the CRC/SHA1/MD5 etc sum of e.g. a string in ctfe. (Which might make sense for most types as the result could really differ depending on endianness, but it shouldn't matter for UTF8 strings, right?) Maybe I can special case CTFE so that at least UTF8 strings work. BTW: casting from void[][] to ubyte[][] seems to work. I guess this is only an oversight and nothing I could use as a workaround?
