Re: Bug in header file generation
On Monday, 17 October 2016 at 08:03:18 UTC, Satoshi wrote:
On Monday, 17 October 2016 at 07:54:33 UTC, Mike Parker wrote:
On Monday, 17 October 2016 at 07:50:17 UTC, Satoshi wrote:
On Saturday, 15 October 2016 at 06:55:31 UTC, Uplink_Coder
wrote:
On Saturday, 15 October 2016 at 06:51:44 UTC, Satoshi wrote:
Hello,
can someone look at this quite simple bug in dmd please?
https://issues.dlang.org/show_bug.cgi?id=16590
I cannot release non-opensource libraries without this.
It is exported correctly, but when I create it like:
class TestClass {
int aa;
ref foo() { // without auto
return aa;
}
}
it is exported like:
class TestClass {
int aa;
ref foo(); // Cannot deduce return type
}
Is there something preventing you from declaring the return
type?
ref int foo() { ... }
no, but I just try to export headers on druntime and phobos and
found this bug.
Thanks for the report.
Could you also post in in bugzilla ?
Thanks!
Re: Reducing the cost of autodecoding
On Sunday, 16 October 2016 at 07:59:16 UTC, Patrick Schluter
wrote:
Here my version. It's probably not the shortest (100 ligns of
assembly with LDC) but it is correct and has following
properties:
- Performance proportional to the encoding length
- Detects Invalid byte sequences
- Detects Overlong encodings
- Detects Invalid code points
I put the exception to be comparable to other routines but
Unicode specifies that it is preferable to not abort on
encoding errors (to avoid denial of service attacks).
dchar myFront2(ref char[] str)
{
dchar c0 = str.ptr[0];
if(c0 < 0x80) {
return c0;
}
else if(str.length > 1) {
dchar c1 = str.ptr[1];
if(c0 < 0xE0 && (c1 & 0xC0) == 0x80) {
c1 = ((c0 & 0x1F) << 6)|(c1 & 0x3F);
if(c1 < 0x80) goto Linvalid;
return c1;
}
else if(str.length > 2) {
dchar c2 = str.ptr[2];
if(c0 < 0xF0 && (c1 & 0xC0) == 0x80 && (c2 & 0xC0) ==
0x80) {
c2 = ((c0 & 0x0F) << 12)|((c1 & 0x3F) << 6)|(c2 & 0x3F);
if(c2 < 0x800) goto Linvalid;
return c2;
}
else if(str.length > 3) {
dchar c3 = str.ptr[3];
if(c0 < 0xF5 && (c1 & 0xC0) == 0x80 && (c2 & 0xC0) ==
0x80 && (c3 & 0xC0) == 0x80) {
c3 = ((c0 & 0x07) << 16)|((c1 & 0x3F) << 12)|((c2 &
0x3F) << 6)|(c3 & 0x3F);
if(c3 < 0x1 || c3 > 0x10) goto Linvalid;
return c3;
}
}
}
}
Linvalid:
throw new Exception("yadayada");
//assert(myFront2(['\xC2','\xA2'])==0xA3);
}
This looks quite slow.
We already have a correct version in utf.decodeImpl.
The goal here was to find a small and fast alternative.
Re: core.intrinsics
On Saturday, 15 October 2016 at 10:17:09 UTC, Matthias Bentrup wrote: You could turn "hints" that can possibly create invalid code automatically into assertions in non-release builds. Or let the user add an assertion and use the "turn assert() into assume()" idea for release builds. I cannot think of any hints the would produce incorrect code. Hints may create terribly inefficient code if they are wrong. But incorrect code ... no examples come to mind.
Re: Reducing the cost of autodecoding
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter wrote: At least with that lookup table below, you can detect isolated continuation bytes (192 and 193) and invalid codes (above 244). __gshared static immutable ubyte[] charWidthTab = [ 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ]; length 5 and 6 need not to be tested specifically for your goto. If you use 0 instead of 1 the length check will suffice for throwing on invalid.
Re: Reducing the cost of autodecoding
It can also be written like this producing smaller code.
But it the cost of slower decoding.
dchar myFront(ref char[] str) pure
{
dchar c = cast(dchar) str.ptr[0];
if (c & 128)
{
if (c & 64)
{
int idx = 0;
int l = charWidthTab.ptr[c - 192];
if (str.length < l)
goto Linvalid;
c = 0;
l--;
while(l) {
l--;
c |= str.ptr[idx++];
c <<= 6;
}
c |= str.ptr[idx];
}
else
Linvalid : throw new Exception("yadayada");
}
return c;
}
Re: Bug in header file generation
On Saturday, 15 October 2016 at 06:51:44 UTC, Satoshi wrote: Hello, can someone look at this quite simple bug in dmd please? https://issues.dlang.org/show_bug.cgi?id=16590 I cannot release non-opensource libraries without this. You mean auto ref right ? please attach a small test-case. You can force the function body to be there by making it a template just give it another pair of parens.
