Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 20:09:30 UTC, Andrei Alexandrescu wrote:
On 7/1/16 3:43 PM, Patrick Schluter wrote:
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu
wrote:
https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
That
do {
} while(0)
construct is ridiculous. It's cargo cult at its worst.
That escalated quickly. -- Andrei
Nothing personal. As I said in the initial message, I had to put
up with that construct for the last 15 years because my colleague
loves it. So I had ample time to learn to hate it with a passion.
Re: string encryption
On 07/02/2016 12:23 AM, Hiemlick Hiemlicker wrote: This also seems like a bug in D because manifest constants used as sole arguments to ctfe'able functions should be replaced by the function result. No. There are functions that don't have any dynamic input, but still take a long time to finish or don't finish at all. Eagerly attempting CTFE on these would be bad. The compiler is supposed to produce a binary, which can then be run to make the computation. The compiler is not supposed to eagerly act as an interpreter and take forever to make the computation itself.
Re: string encryption
On Saturday, 2 July 2016 at 01:31:17 UTC, Hiemlick Hiemlicker wrote: But you are declaring string 1 and string 2 an enum. If you declare them as a string then the original is embedded in the binary! I don't know why that would change anything but it does. The reason it matter is because if one wanted to do a quick change of strings from normal to encrypted, they would also have to change all string variables to enums. This is known as a manifest constant [1]: enum myVal = 10; When the compiler encounters any use of myVal, it will insert its value directly at the point of usage. myVal will not appear in the data segment. You cannot take its address. [1] http://dlang.org/spec/enum.html#manifest_constants
Re: string encryption
On Saturday, 2 July 2016 at 01:31:17 UTC, Hiemlick Hiemlicker wrote: On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote: On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker wrote: On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote: On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: Wait! It almost works! ;) But you are declaring string 1 and string 2 an enum. On purpose If you declare them as a string then the original is embedded in the binary! Ditto. If you don't store it at compile time, the non-encrypted form, so the literal, will be in the DATA segment.
Re: string encryption
On Saturday, 2 July 2016 at 00:29:45 UTC, Adam D. Ruppe wrote:
On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker
wrote:
Is there a way to write a wrapper around such that
mystring s = "a string that will be converted and not appear
in binary";
writeln(s);
You just need to put a `string toString() { return whatever; }`
function on `mystring`
Thanks. That did the trick.
No unencrypted string in the binary and hopefully a drop in
replacement for string.
Although, iteration of a string that was encrypted could be
problematic.
I'll have to be careful where I use this.
Re: string encryption
On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote:
On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker
wrote:
On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote:
On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker
wrote:
I've tried playing with opCall, opAssign, alias this,
@property but writeln(s) never calls what I thought it should.
I thought s was short for s() if s was a property. having
alias this decrypt and decrypt being a @property should allow
this to work?
I think the best you can do is this:
import std.stdio;
struct KryptedString(string value)
{
alias get this;
string get() @property
{
return "decrypt \"" ~ value ~ "\" here";
}
}
template krypt(string value)
{
string process()
{
return "crypted"; // encrypt the template param
}
enum krypt = KryptedString!process();
}
enum string1 = krypt!"blablabla";
enum string2 = krypt!"blablablabla";
void main()
{
writeln(string1);
writeln(string2);
}
The syntax is not so bad.
enum KryptedString string1 = "blablabla";
is impossible or maybe I don't know the trick yet.
Wait! It almost works! ;)
But you are declaring string 1 and string 2 an enum. If you
declare them as a string then the original is embedded in the
binary!
I don't know why that would change anything but it does.
The reason it matter is because if one wanted to do a quick
change of strings from normal to encrypted, they would also have
to change all string variables to enums.
import std.stdio;
struct KryptedString(string value)
{
alias get this;
string get() @property
{
string q;
foreach(c; value)
q ~= c + 1;
return q;
}
}
template krypt(string value)
{
string process()
{
string q;
foreach(c; value)
q ~= c - 1;
return q;
}
enum krypt = KryptedString!process();
}
string string1 = krypt!"Testing 1 2 3 4";
string string2 = krypt!"ttbbccd";
void main()
{
writeln(string1);
writeln(string2);
getchar();
}
I guess one could do
enum string1e = krypt!"Testing 1 2 3 4";
then
string string1 = string1e;
but the goal is to make as clean as possible ;)
Re: -dip25 switch: time to make it always on?
On Wednesday, June 29, 2016 02:40:45 Walter Bright via Digitalmars-d wrote: > It was added for 2.067 back in March of 2015: > > https://dlang.org/changelog/2.067.0.html > > It's been a strong success. Time to make it the default instead of enabled > by a switch? Well, I don't know how you can really tell whether it's been a success or not. The only real evidence we have has to do with druntime, Phobos, and maybe dmd - which certainly isn't nothing, but we really don't know how much anyone has been using it. I suspect that almost no one has been. And if we want to test it more globally, we're pretty much going to have to make it the default (presumably by initially making it just print warning messages which aren't affected by -w so as to avoid breaking code) and see what happens. I certainly wouldn't suggest just making what -dip25 does suddenly apply to everyone with no transition period. That being said, I think that we need to be very sure that this is where we want to go, and there always seems to have been a fair bit of disagreement over that. Personally, I don't know. One big problem I see is that having an attribute that you have to use in @safe code but not in other code really does not play well with attribute inference, and you were talking about making attribute inference even more widespread as part of the ref-counting improvements. And while I know that there are not a lot of open bugs related to -dip25, it didn't exactly make me feel confident in the implementation, when I played around with it a few minutes ago and hit a bug right away: https://issues.dlang.org/show_bug.cgi?id=16226 I honestly expect that almost no one has been using -dip25 (I certainly haven't), and I think that saying that it's been a success is overstating things considerably. If we want to see how well it works, we're really going to need to make it the default behavior (presumably not as an error to begin with), though obviously, that's going to be a problem if we then decide that it was a mistake. :| I think that dip25 may very well be the right way to go, but I also fear that it's too narrow to really get us what we want - similar to how inout helps with certain things but doesn't really get us what we want because it's too narrow. So, I'm not opposed to moving forward with it, but I'm not at all confident that it's the right choice. - Jonathan M Davis
Bug in D type inferencing
public struct Foo
{
public void Create(T)(uint delegate(T) c, T param)
{
}
}
Foo f;
f.Create((x) { }, "asdf");
cannot deduce arguments compiler error.
Surely D can figure out that T is a string?
If one simply changes this to
public struct Foo(T)
{
public void Create(uint delegate(T) c, T param)
{
}
}
and
Foo!string f;
everything works.
The second parameter is a string so why not infer that T is a
string?
Also, if one does
f.Create((string x) { }, "asdf");
Then it works. Seems like a blatant limitation in D's type
inferencing system.
Re: string encryption
On Saturday, 2 July 2016 at 00:39:57 UTC, Basile B. wrote: The syntax is not so bad. enum KryptedString string1 = "blablabla"; is impossible or maybe I don't know the trick yet. That's a constructor on KryptedString that takes a string.
Re: Do you want support for CTFE coverage ?
On Saturday, 2 July 2016 at 00:38:56 UTC, Stefan Koch wrote: On Saturday, 2 July 2016 at 00:34:05 UTC, Walter Bright wrote: On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and coverage tested that way. Fair enough :) execpt for code guarded by if (__ctfe) What I'd like is that the code inside 'if(__ctfe)' branches gets ignored in the coverage results, so that 100% can be reached. for normal CTFE, to use assert() instead of static assert() does the trick.
Re: Do you want support for CTFE coverage ?
On Saturday, 2 July 2016 at 00:34:05 UTC, Walter Bright wrote: On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and coverage tested that way. Fair enough :) execpt for code guarded by if (__ctfe)
Re: string encryption
On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker
wrote:
On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote:
On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker
wrote:
I've tried playing with opCall, opAssign, alias this, @property
but writeln(s) never calls what I thought it should.
I thought s was short for s() if s was a property. having alias
this decrypt and decrypt being a @property should allow this to
work?
I think the best you can do is this:
import std.stdio;
struct KryptedString(string value)
{
alias get this;
string get() @property
{
return "decrypt \"" ~ value ~ "\" here";
}
}
template krypt(string value)
{
string process()
{
return "crypted"; // encrypt the template param
}
enum krypt = KryptedString!process();
}
enum string1 = krypt!"blablabla";
enum string2 = krypt!"blablablabla";
void main()
{
writeln(string1);
writeln(string2);
}
The syntax is not so bad.
enum KryptedString string1 = "blablabla";
is impossible or maybe I don't know the trick yet.
Re: Do you want support for CTFE coverage ?
On 7/1/2016 1:29 PM, Stefan Koch wrote: Do you want to see coverage for code executed at CTFE ? It's not necessary since CTFE code can all be executed at runtime, and coverage tested that way.
Re: string encryption
On Saturday, 2 July 2016 at 00:05:14 UTC, Hiemlick Hiemlicker
wrote:
Is there a way to write a wrapper around such that
mystring s = "a string that will be converted and not appear in
binary";
writeln(s);
You just need to put a `string toString() { return whatever; }`
function on `mystring`
Re: Do you want support for CTFE coverage ?
there is no need in that, absolutely. CTFE is undebugabble anyway (and pragma(msg) not really helps -- i'm saying that as a fan of printf debugger), unittesting it is silly and so on. after all, as CTFE *should* behave the same if it is done in runtime, one can always test and debug CTFE code as "normal" code before using. so, i say: "don't bother".
Re: string encryption
On Friday, 1 July 2016 at 23:55:08 UTC, Adam D. Ruppe wrote:
On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker
wrote:
ok. For some reason I thought CTFE's applied to normal
functions but I realize that doesn't make a lot of sense.
It is applied to normal functions, just when they are used in
the right context.
int a = factorial(3); // normal runtime
static a = factorial(3); // CTFE
Same function, but different contexts. In a static or enum
variable, it is CTFE'd. In a normal runtime variable, it is
runtime interpreted.
Yes, of course. Do D names change depending on -debug vs
-release?
No, he meant -g, not -debug. That puts the function names in
the executable, whereas they might not be there without it
(though they might be too... I don't think this makes much of a
difference)
See my post here:
http://stackoverflow.com/a/38149801/1457000
tbh, I don't think encrypting strings is really worth it
either, they aren't hard to extract anyway.
I'm not too concerned about the attacker seeing them because
they will have to watch every decryption to get the string(or
possibly write a utility to automate the decryption).
And that's not really hard where's the string going anyway?
You might want it in a separate file that you can optionally
encrypt or ask for it from the user.
Ok, Well, I'm curious. I've been string to write a string
replacement that does the encryption and decryption. It could be
used for other things like automatic language translation, etc..
Is there a way to write a wrapper around such that
mystring s = "a string that will be converted and not appear in
binary";
writeln(s);
where s acts as a function that is called to transform the string?
There are two transformations that take place. One is at compile
time on the string assignment. The other is at the "call site".
I can't seem to get anything to actually work correctly. writeln
always ends up writing `mystring("whatever the first
transformation is")`.
a test case
import std.stdio;
template enString(string s)
{
string processor()
{
string q;
foreach(c; s)
q ~= c + 1;
return q;
}
enum enString = processor();
}
template e(string s)
{
de_enString e()
{
de_enString x;
x.val = enString!(s);
return x;
}
}
struct de_enString
{
string val;
string decrypt()
{
string q;
foreach(c; val)
q ~= c - 1;
return q;
}
alias this decrypt;
}
void main()
{
auto s = e!("This is an encrypted string");
writeln(s);
getchar();
}
I've tried playing with opCall, opAssign, alias this, @property
but writeln(s) never calls what I thought it should.
I thought s was short for s() if s was a property. having alias
this decrypt and decrypt being a @property should allow this to
work?
Re: string encryption
On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote: This also seems like a bug in D because manifest constants used as sole arguments to ctfe'able functions should be replaced by the function result. I wouldn't call it a bug, but it could be seen as an enhancement request, in a similar vein to keeping the unused ctfe functions themselves out of the binary.
Re: string encryption
On Friday, 1 July 2016 at 23:23:19 UTC, Hiemlick Hiemlicker wrote: ok. For some reason I thought CTFE's applied to normal functions but I realize that doesn't make a lot of sense. It is applied to normal functions, just when they are used in the right context. int a = factorial(3); // normal runtime static a = factorial(3); // CTFE Same function, but different contexts. In a static or enum variable, it is CTFE'd. In a normal runtime variable, it is runtime interpreted. Yes, of course. Do D names change depending on -debug vs -release? No, he meant -g, not -debug. That puts the function names in the executable, whereas they might not be there without it (though they might be too... I don't think this makes much of a difference) See my post here: http://stackoverflow.com/a/38149801/1457000 tbh, I don't think encrypting strings is really worth it either, they aren't hard to extract anyway. I'm not too concerned about the attacker seeing them because they will have to watch every decryption to get the string(or possibly write a utility to automate the decryption). And that's not really hard where's the string going anyway? You might want it in a separate file that you can optionally encrypt or ask for it from the user.
Re: string encryption
On Friday, 1 July 2016 at 22:56:48 UTC, Basile B. wrote:
On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker
wrote:
I know this is probably a lot to ask for an many won't see the
point, but a secure program should not expose readable
strings, it makes it far too easy for the attacker to see what
is going on.
Is it possible to encrypt every static string in D and decrypt
before it is output in an automatic fashion?
Even something like
e{This is an encrypted string}
which encrypts the string using a user defined function(which
is ctfe'able) is better than nothing.
Even a simple xor type of cypher is better than nothing.
Obviously optional.
The problem is that there is no way to encrypt strings in the
binary through code because one must pass express the string
non-encrypted to the encryption function.
encrypt("This string will still end up in the binary");
even though the string is only used once, at the encryption
call site. It seems D won't replace
encrypt("This string will still end up in the binary");
with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or
whatever the ctfe value of encrypt actually is.
This also seems like a bug in D because manifest constants
used as sole arguments to ctfe'able functions should be
replaced by the function result.
e.g.,
factorial(3) should be replaced by 6 and the function should
never be called at run time. This is the whole point of ctfe,
is it not?
I'm not actually sure if the functions are ctfe'ed and the
un-encrypted string is just stored in the binary or what but
it's there
import std.stdio;
string e(string s)
{
string q;
foreach(c; s)
q ~= c + 1;
return q;
}
void main()
{
writeln(e("What is this string doing in the binary?"));
}
You must make a template that follows this pattern:
template KrypticString(string s)
{
string processor()
{
return /*do some stuff here on 's'*/ "";
}
enum KrypticString = processor();
}
It's already used in phobos for example for octal() and
hexString(). Also seen i dont remember where, for a float
format.
ok. For some reason I thought CTFE's applied to normal functions
but I realize that doesn't make a lot of sense. (would be nice
but most functions are not CTFE'able and the compiler would have
trouble figuring that out)
But another important thing is that you must absolutely not
release with -debug.
Strings are a thing but every one who has made the thug with
IDA knows that the most usefull informations are the "Names"
and not the "strings". The calls to the OS API can't be easily
hidden, they are always in the "Names" but D functions names
can.
Yes, of course. Do D names change depending on -debug vs -release?
For example it's even not worth crypting the strings if the
attacker can see
_D4main7decryptFAyaZAya
in the "Names", because in this case he "just" has to put a
breakpoint on the C3 of the matching function, look for the
decrypted string in memory, and bookmark the static addresses
of the parameters passed to this function during the execution.
Also, if you take a minute to think a bit you'll find that
cryptic strings will hit the eyes of the attacker quite
quickly: "mmmh why is the content crypted ?!, let's see
that...".
I'm not too concerned about the attacker seeing them because they
will have to watch every decryption to get the string(or possibly
write a utility to automate the decryption).
If everything is encrypted it will give the attacker grief far
more than being decrypted.
If pretty much every string is encrypted then it will make his
life a little more difficult I would think. After all, it is
impossible to completely stop an attacker given enough time and
energy. The goal is to make it not worth it.
Also, Is there a simple way to make this work for "direct" output:
writeln(de_encrypt!("This is my string"));
it encrypts it at compile time but decrypts it at run time.(hence
no binary)
Alternatively, treat every string as a call to an anonymous
function that decrypts it at runtime(possibly using different
cypher).
e.g.,
enstring s = "This is really an encrypted string function";
enstring could wrap opCall which decrypts it when used. This
might be a drop in replacement for string?
s() calls the decryption function, which is uniquely generated
for each string. We can drop the ()...
This would definitely add an order of magnitude to the complexity
of decoding the strings.
Re: string encryption
On Friday, 1 July 2016 at 22:55:21 UTC, qznc wrote:
On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker
wrote:
It seems D won't replace
encrypt("This string will still end up in the binary");
with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or
whatever the ctfe value of encrypt actually is.
This also seems like a bug in D because manifest constants
used as sole arguments to ctfe'able functions should be
replaced by the function result.
CTFE is explicit. You could make it `encrypt!"encrypted at
compile-time"`. Then let encrypt return some struct, which
decrypts at runtime.
? I thought CTFE was for normal functions?
I guess I was mistaken ;/
Re: string encryption
On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote:
I know this is probably a lot to ask for an many won't see the
point, but a secure program should not expose readable strings,
it makes it far too easy for the attacker to see what is going
on.
Is it possible to encrypt every static string in D and decrypt
before it is output in an automatic fashion?
Even something like
e{This is an encrypted string}
which encrypts the string using a user defined function(which
is ctfe'able) is better than nothing.
Even a simple xor type of cypher is better than nothing.
Obviously optional.
The problem is that there is no way to encrypt strings in the
binary through code because one must pass express the string
non-encrypted to the encryption function.
encrypt("This string will still end up in the binary");
even though the string is only used once, at the encryption
call site. It seems D won't replace
encrypt("This string will still end up in the binary");
with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or
whatever the ctfe value of encrypt actually is.
This also seems like a bug in D because manifest constants used
as sole arguments to ctfe'able functions should be replaced by
the function result.
e.g.,
factorial(3) should be replaced by 6 and the function should
never be called at run time. This is the whole point of ctfe,
is it not?
I'm not actually sure if the functions are ctfe'ed and the
un-encrypted string is just stored in the binary or what but
it's there
import std.stdio;
string e(string s)
{
string q;
foreach(c; s)
q ~= c + 1;
return q;
}
void main()
{
writeln(e("What is this string doing in the binary?"));
}
You must make a template that follows this pattern:
template KrypticString(string s)
{
string processor()
{
return /*do some stuff here on 's'*/ "";
}
enum KrypticString = processor();
}
It's already used in phobos for example for octal() and
hexString(). Also seen i dont remember where, for a float format.
But another important thing is that you must absolutely not
release with -debug.
Strings are a thing but every one who has made the thug with IDA
knows that the most usefull informations are the "Names" and not
the "strings". The calls to the OS API can't be easily hidden,
they are always in the "Names" but D functions names can.
For example it's even not worth crypting the strings if the
attacker can see
_D4main7decryptFAyaZAya
in the "Names", because in this case he "just" has to put a
breakpoint on the C3 of the matching function, look for the
decrypted string in memory, and bookmark the static addresses of
the parameters passed to this function during the execution.
Also, if you take a minute to think a bit you'll find that
cryptic strings will hit the eyes of the attacker quite quickly:
"mmmh why is the content crypted ?!, let's see that...".
Re: string encryption
On Friday, 1 July 2016 at 22:23:23 UTC, Hiemlick Hiemlicker wrote:
It seems D won't replace
encrypt("This string will still end up in the binary");
with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or
whatever the ctfe value of encrypt actually is.
This also seems like a bug in D because manifest constants used
as sole arguments to ctfe'able functions should be replaced by
the function result.
CTFE is explicit. You could make it `encrypt!"encrypted at
compile-time"`. Then let encrypt return some struct, which
decrypts at runtime.
string encryption
I know this is probably a lot to ask for an many won't see the
point, but a secure program should not expose readable strings,
it makes it far too easy for the attacker to see what is going on.
Is it possible to encrypt every static string in D and decrypt
before it is output in an automatic fashion?
Even something like
e{This is an encrypted string}
which encrypts the string using a user defined function(which is
ctfe'able) is better than nothing.
Even a simple xor type of cypher is better than nothing.
Obviously optional.
The problem is that there is no way to encrypt strings in the
binary through code because one must pass express the string
non-encrypted to the encryption function.
encrypt("This string will still end up in the binary");
even though the string is only used once, at the encryption call
site. It seems D won't replace
encrypt("This string will still end up in the binary");
with "skadf2903jskdlfaos;e;fo;aisjdfja;soejfjjfjfjfjfjfeij" or
whatever the ctfe value of encrypt actually is.
This also seems like a bug in D because manifest constants used
as sole arguments to ctfe'able functions should be replaced by
the function result.
e.g.,
factorial(3) should be replaced by 6 and the function should
never be called at run time. This is the whole point of ctfe, is
it not?
I'm not actually sure if the functions are ctfe'ed and the
un-encrypted string is just stored in the binary or what but it's
there
import std.stdio;
string e(string s)
{
string q;
foreach(c; s)
q ~= c + 1;
return q;
}
void main()
{
writeln(e("What is this string doing in the binary?"));
}
Re: Has someone encountered similar issues with -cov?
On 7/1/16 4:08 PM, Andrei Alexandrescu wrote: On 7/1/16 2:46 PM, Steven Schveighoffer wrote: On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov. Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Suppose one wants to check if you've covered all cases inside the while loop (with breaks or returns). Then, one would WANT to see 0 coverage there (non-zero coverage would mean an error in logic). To remove that feedback would mess up someone else's use case. This argument is phony. Unconvinced. -- Andrei I don't use while(0), so I have to invent a hypothetical use case. It's not phony. I could just as easily say that your coding style is illegitimate, and you should use while(true) instead (and thereby get 100% coverage analysis). But I'm not saying that. There is a legitimate difference between breaking out of the while loop using breaks, and breaking out using the while(0) condition. Why do you want coverage analysis to ignore that difference? Why would someone else's use case that relies on executing or not executing while(0) be invalid? -Steve
Do you want support for CTFE coverage ?
Hi, Exactly as per title. Do you want to see coverage for code executed at CTFE ? I ask because it is slightly tricky to support this and it needs to be factored in early in design. And please off-topic or thread hijacking this time. Thanks!
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 19:43:05 UTC, Patrick Schluter wrote: It looks like a loop, but isn't one. It doesn't look like a goto, but is one. Yes, it looks buggy, and the -cov did the right thing by marking it as uncovered as this could be a serious and difficult to find bug. I wonder why people write such ugly and misleading code deliberately? The compiler turns it into jumps anyway and in this case a bool or gotos are much more readable and not slower. In fact, a statemachine implemented as gotos can be very clean, efficient and easy to debug. It's a matter of structuring the code layout.
Re: Has someone encountered similar issues with -cov?
On 7/1/16 3:43 PM, Patrick Schluter wrote:
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
That
do {
} while(0)
construct is ridiculous. It's cargo cult at its worst.
That escalated quickly. -- Andrei
Re: Has someone encountered similar issues with -cov?
On 7/1/16 2:46 PM, Steven Schveighoffer wrote: On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov. Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Suppose one wants to check if you've covered all cases inside the while loop (with breaks or returns). Then, one would WANT to see 0 coverage there (non-zero coverage would mean an error in logic). To remove that feedback would mess up someone else's use case. This argument is phony. Unconvinced. -- Andrei
Re: Has someone encountered similar issues with -cov?
On 7/1/16 2:27 PM, Chris wrote: On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote: Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Not sure if it's pure punctuation. It is after all a statement checking for a condition What is the condition? -- Andrei
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
That
do {
} while(0)
construct is ridiculous. It's cargo cult at its worst. It is NOT
more readable than an honest to god goto. It's an obfuscated way
to write naughty gotos without the guilt of sinning (I
deliberately use religous vocabulary because it is a religious
disease). It's the goto of the hypocrits.
Sorry if I sound harsh, but I share a project (in C) with a
colleague who loves that construct and after almost 15 years of
having to debug that sh... I can affirm that that construct is a
scourge and deserves all the scorn that can be heaped on it.
It looks like a loop, but isn't one.
It doesn't look like a goto, but is one.
It's horribly difficult to amend, especially if there is actually
a real loop somewhere around or inside it.
It pushes the user to write unnecessary big functions (anecdote,
I modified once a 200 lines do while(0) behemoth that could be
reduced to 4 functions of 10 lines each and a small loop. After
conversion and simplification I discovered that the original
didn't even cover all functional cases and leaked some memory).
I don't think it makes even an inkling of sense to use it in D as
there are real language constructs that can cleanly replace it
(scope, try/catch/finally, destructors, etc.).
Re: Logical location of template instantiations
On Friday, 1 July 2016 at 19:13:45 UTC, Steven Schveighoffer wrote: On 7/1/16 3:02 PM, Timon Gehr wrote: The current module (that declares 'S') might not be the only module that uses emplace to construct 'S' instances. We want to hide the constructor of 'S' from other modules, but not from the current module. But both modules get identical template instances, so either both see the private constructor (through emplace), or none does. To fix this properly, there should hence be a way for the two modules to receive distinct template instances. Emplace needs a constructor alias parameter. -Steve Yes, this looks like a sensible solution.
Re: Logical location of template instantiations
On 7/1/16 3:02 PM, Timon Gehr wrote: The current module (that declares 'S') might not be the only module that uses emplace to construct 'S' instances. We want to hide the constructor of 'S' from other modules, but not from the current module. But both modules get identical template instances, so either both see the private constructor (through emplace), or none does. To fix this properly, there should hence be a way for the two modules to receive distinct template instances. Emplace needs a constructor alias parameter. -Steve
Re: Logical location of template instantiations
On 27.06.2016 18:25, Lodovico Giaretta wrote:
import std.conv, core.memory;
struct S
{
int x;
private this(int val)
{
x = val;
}
}
void main()
{
auto ptr = cast(S*)GC.malloc(S.sizeof);
auto s = ptr.emplace(3);
}
This code does not work, as the call `ptr.emplace(3)` creates a new
concrete implementation of emplace with parameters `S` and `int`, which
logically belongs to module std.conv, and so has no access to the
private constructor.
But, logically speaking, as I'm able to construct objects of S, I should
also be able to emplace them (which is the same thing, logically) while
inside my module. What I mean is that in this situation it would be
better if the call `ptr.emplace(3)` created a new concrete
implementation of emplace inside the module that called it, to have the
correct access permissions.
This is not the first time I run into this limitation (not only with
functions, but also with structs), so I wonder: wouldn't it be worth a
way to get this behaviour?
Thank you for your time.
Lodovico Giaretta
The current module (that declares 'S') might not be the only module that
uses emplace to construct 'S' instances. We want to hide the constructor
of 'S' from other modules, but not from the current module.
But both modules get identical template instances, so either both see
the private constructor (through emplace), or none does. To fix this
properly, there should hence be a way for the two modules to receive
distinct template instances.
Re: Logical location of template instantiations
On 01/07/16 16:14, Steven Schveighoffer wrote: Right, but this puts allocators at a lower footing than the GC which has no problem with private ctors. I would have expected to be able to build using allocators and private ctors. It's possible to bypass protection using pointers. -- /Jacob Carlborg
Re: Has someone encountered similar issues with -cov?
On 7/1/16 2:15 PM, Andrei Alexandrescu wrote: On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov. Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Suppose one wants to check if you've covered all cases inside the while loop (with breaks or returns). Then, one would WANT to see 0 coverage there (non-zero coverage would mean an error in logic). To remove that feedback would mess up someone else's use case. -Steve
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 18:15:56 UTC, Andrei Alexandrescu wrote: Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei Not sure if it's pure punctuation. It is after all a statement checking for a condition, i.e. actually doing something. The fact that you bypass this check should not concern -cov, whose job it is to see whether a task is executed or not. You cannot expect -cov to do the optimizer's job on top of that. In fact one could argue that it shouldn't make assumptions.
Re: Has someone encountered similar issues with -cov?
On 7/1/16 2:05 PM, Chris wrote: On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov. Yah it's a bit subtle. That line is in fact pure punctuation, so even though there's no flow through it that's totally fine (as much as you wouldn't expect a line with a "}" to show no coverage). -- Andrei
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I fail to see why it should not mark it as uncovered in the `cube` example. After all the statement is never covered, because `do` executes before the condition in `while` is checked. Unless you mean it should be optimized away by the compiler, which in turn has nothing to do with -cov.
Re: Logical location of template instantiations
On Monday, 27 June 2016 at 16:25:27 UTC, Lodovico Giaretta wrote: [...] This is not the first time I run into this limitation (not only with functions, but also with structs), so I wonder: wouldn't it be worth a way to get this behaviour? Yes it would be worth. Several ppl have already hit this wall, including me. You can vote for this enhancement, it proposes to give a "super visual acuity" to traits such as getMember or getOverloads: https://issues.dlang.org/show_bug.cgi?id=15371 You might also look at `hasUDA` from std.traits because it used to be affected by this issue.
Re: Logical location of template instantiations
On Friday, 1 July 2016 at 14:14:00 UTC, Steven Schveighoffer wrote: On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: I wonder what the plans are for std.allocator on this, as I would think it would run into the same issues. Andrei? emplace only works with accessible constructors. I understand sometimes it's reasonable to ask for more flexibility, but there are limitations. Right, but this puts allocators at a lower footing than the GC which has no problem with private ctors. I would have expected to be able to build using allocators and private ctors. -Steve +1
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei I've reported this one a while back: https://issues.dlang.org/show_bug.cgi?id=15590 if (__ctfe) branches are a problem because they really prevent to reach 100% coverage. D code similar to std.traits content is also a problem, it's never executed at run-time.
Re: Has someone encountered similar issues with -cov?
On Friday, 1 July 2016 at 16:30:41 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei Yeah: https://issues.dlang.org/buglist.cgi?quicksearch=coverage&list_id=209269
Has someone encountered similar issues with -cov?
https://issues.dlang.org/show_bug.cgi?id=16224 -- Andrei
Re: Logical location of template instantiations
On 7/1/16 9:46 AM, Andrei Alexandrescu wrote: On 07/01/2016 09:08 AM, Steven Schveighoffer wrote: I wonder what the plans are for std.allocator on this, as I would think it would run into the same issues. Andrei? emplace only works with accessible constructors. I understand sometimes it's reasonable to ask for more flexibility, but there are limitations. Right, but this puts allocators at a lower footing than the GC which has no problem with private ctors. I would have expected to be able to build using allocators and private ctors. -Steve
Re: Logical location of template instantiations
On 01/07/16 15:46, Andrei Alexandrescu wrote: emplace only works with accessible constructors. I understand sometimes it's reasonable to ask for more flexibility, but there are limitations. It's possible to bypass the protection using a pointer. An alternative would be to not invoke the constructor and let the users to that themselves. -- /Jacob Carlborg
Re: Logical location of template instantiations
On 07/01/2016 09:08 AM, Steven Schveighoffer wrote:
On 6/27/16 12:25 PM, Lodovico Giaretta wrote:
import std.conv, core.memory;
struct S
{
int x;
private this(int val)
{
x = val;
}
}
void main()
{
auto ptr = cast(S*)GC.malloc(S.sizeof);
auto s = ptr.emplace(3);
}
This code does not work, as the call `ptr.emplace(3)` creates a new
concrete implementation of emplace with parameters `S` and `int`, which
logically belongs to module std.conv, and so has no access to the
private constructor.
But, logically speaking, as I'm able to construct objects of S, I should
also be able to emplace them (which is the same thing, logically) while
inside my module. What I mean is that in this situation it would be
better if the call `ptr.emplace(3)` created a new concrete
implementation of emplace inside the module that called it, to have the
correct access permissions.
I wonder what the plans are for std.allocator on this, as I would think
it would run into the same issues. Andrei?
emplace only works with accessible constructors. I understand sometimes
it's reasonable to ask for more flexibility, but there are limitations.
-- Andrei
Re: Logical location of template instantiations
On 01/07/16 11:57, Lodovico Giaretta wrote: Ping... Maybe I'm just saying bullshit, but... Am I really the only one who faced this need? You're not the only one, it's been brought up before. A solution/workaround is that "emplace" invokes the constructor using a function pointer, what will bypass the protection. -- /Jacob Carlborg
Re: Call to Action: making Phobos @safe
On Thursday, 30 June 2016 at 21:55:33 UTC, Seb wrote: On Thursday, 30 June 2016 at 21:31:25 UTC, Walter Bright wrote: On 6/30/2016 11:54 AM, Bennet Leff wrote: On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek wrote: [...] Could you elaborate on list option 9 "create a module that enables code to be run on GPU." Wouldn't the Derelict OpenCL bindings satisfy that need? I don't know. John Colvin is working on this, he could give a far better appraisal of the state. Some pointers: https://github.com/John-Colvin/clWrap http://dconf.org/2016/talks/colvin.html Thanks I'll take a further look although it doesn't look like his project is ready for more contributors to add to it yet.
Re: Logical location of template instantiations
On 6/27/16 12:25 PM, Lodovico Giaretta wrote:
import std.conv, core.memory;
struct S
{
int x;
private this(int val)
{
x = val;
}
}
void main()
{
auto ptr = cast(S*)GC.malloc(S.sizeof);
auto s = ptr.emplace(3);
}
This code does not work, as the call `ptr.emplace(3)` creates a new
concrete implementation of emplace with parameters `S` and `int`, which
logically belongs to module std.conv, and so has no access to the
private constructor.
But, logically speaking, as I'm able to construct objects of S, I should
also be able to emplace them (which is the same thing, logically) while
inside my module. What I mean is that in this situation it would be
better if the call `ptr.emplace(3)` created a new concrete
implementation of emplace inside the module that called it, to have the
correct access permissions.
I wonder what the plans are for std.allocator on this, as I would think
it would run into the same issues. Andrei?
-Steve
Re: post 2.071 mixin template & import rules
On 7/1/16 1:42 AM, captaindet wrote:
apparently starting with 2.071 import declarations are not treated as
declarations in the sense of mixin templates anymore. meaning that whole
module imports (private and public) in mixin template definitions are
not inserted into the instantiating scope anymore. neither if
instantiated on module level, nor if in a class etc. it is not that the
look-up order has changed for them, they are blatantly ignored now.
I understand this position. Note that with the new import rules,
importing a module wholesale into a scope is not nearly as damaging as
before (where everything overrode locals and even module symbols). In
most of the changes, the import succeeds, but is just not selected first
to avoid hijacking. In this case, it looks like the import is simply
ignored. That doesn't make a whole lot of sense.
Even when the import is intended to add a specific member to the
function, this doesn't help. e.g.:
a.d:
module a;
import std.stdio;
struct Foo
{
int x;
void fun() { writeln("fun ", x); }
}
void gun(Foo f) { writeln("gun ", f.x); }
b.d:
module b;
mixin template AddImp (){
import a;
Foo f;
}
c.d:
import b;
struct Bar
{
mixin AddImp;
void bar() {
f.fun();
f.gun(); // worked before, but now fails!
}
}
void main()
{
Bar b;
b.bar;
}
What is the point of disallowing f.gun()? It's literally part of the
intended interface of Foo, why can't that be had? I see no reason to
disallow this. If I defined a gun(Foo f) in c.d, it would override that.
There's no hijacking possible.
In order to properly write AddImp, I'd have to find all the possible
ways that Foo could be used given UFCS, and import those as selected
imports. This is not how it should be IMO. The blunt fix would be I
guess to public import a at module level, but that's opening up all
importers of b to a's code.
-Steve
Re: Logical location of template instantiations
On Friday, 1 July 2016 at 12:08:49 UTC, Lodovico Giaretta wrote: On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully bypassed my issues with this thing, but I wanted to share my thoughts about the need to express this kind of thing (i.e. to give a template instantiation the privileges of the instantiating module), and to know if someone else has some opinion on this matter. Yeah. I don't know if it's _needed_ by enough people or by the language, but a way to force templates to be hijacked while being instantiated (not at point of definition but at instantiation; though I imagine this might prove troublesome for reflection and template identity, somehow) if we want to. The default hygienic behavior is great, but bypassing it when needed is not.
Re: Logical location of template instantiations
On Friday, 1 July 2016 at 11:45:12 UTC, Robert burner Schadek wrote: IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-) Yes, well, I successfully bypassed my issues with this thing, but I wanted to share my thoughts about the need to express this kind of thing (i.e. to give a template instantiation the privileges of the instantiating module), and to know if someone else has some opinion on this matter.
Re: Logical location of template instantiations
IMO, this is one of these places where theory meets practice. Do what works, write a comment explaining the problem, and move on ;-)
Re: DConf Videos
On 7/1/2016 12:17 AM, Mike James wrote: Yeh - it's taking its time. I'm not expecting Lawrence of Arabia quality... I didn't look good riding a camel, so I asked them to edit that out.
Re: Logical location of template instantiations
Ping... Maybe I'm just saying bullshit, but... Am I really the only one who faced this need?
Re: -dip25 switch: time to make it always on?
On 6/29/2016 3:02 AM, Dicebot wrote: There are also plenty of open issues in bugzilla about current implementation : https://issues.dlang.org/buglist.cgi?quicksearch=dip25&list_id=209219 14238 awaits improvements to 'scope'. 15293 has an outstanding PR. The rest either had fixes merged or were not actually -dip25 problems.
Re: post 2.071 mixin template & import rules
On Friday, 1 July 2016 at 05:42:30 UTC, captaindet wrote: it appears that there had been an even more radical change as well with respect to the way mixin templates work. this has not been properly communicated yet. at least i could not find a write-up and a related thread conveyed rather guesswork than knowledge. ( https://forum.dlang.org/post/nl2bgi$2oim$1...@digitalmars.com ) The question is: Was it intentional? Imho, it is weird that template mixin have different behavior than modules with respect to import visibility. I don't see a reason, why a public import should not be exported.
Re: DConf Videos
On Monday, 6 June 2016 at 16:22:18 UTC, Gary Willoughby wrote: On Monday, 6 June 2016 at 10:40:01 UTC, sarn wrote: What's the best source of DConf videos at the moment? Are there are any edited versions released? I'd like to share some of my favourite talks. Also, where are the DConf 2016 videos? I was under the impression that they would be released on YouTube? Yeh - it's taking its time. I'm not expecting Lawrence of Arabia quality... -=mike=-
