www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - cast from void[] to ubyte[] in ctfe

reply Johannes Pfau <nospam example.com> writes:
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?

I need this for a function which accepts any type and passes it's
binary representation to a function only accepting a ubyte[]:
-----------------
digestType!Hash digest(Hash)(scope const(void[])[] data...)
if(isDigest!Hash) {
    Hash hash;
    hash.start();
    foreach(datum; data)
        hash.put(cast(const(ubyte[]))datum);
    return hash.finish();
}
-----------------
Error: array cast from const(void[]) to const(ubyte[]) is not supported
at compile time

I could templatize digest on the data type but shouldn't there be
a way to do this without the additional template bloat?
Jul 13 2012
next sibling parent reply Don Clugston <dac nospam.com> writes:
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.
Jul 13 2012
parent Don Clugston <dac nospam.com> writes:
On 13/07/12 12:52, Johannes Pfau wrote:
 Am Fri, 13 Jul 2012 11:53:07 +0200
 schrieb Don Clugston <dac 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.
Jul 16 2012
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 13 Jul 2012 11:53:07 +0200
schrieb Don Clugston <dac 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?
Jul 13 2012