View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2012
cast from void[] to ubyte[] in ctfe
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?
July 13, 2012
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.
July 13, 2012
Re: cast from void[] to ubyte[] in ctfe
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?
July 16, 2012
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 <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.
Top | Discussion index | About this forum | D home