Thread overview | ||||||
---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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. |
Copyright © 1999-2021 by the D Language Foundation