Re: Some notes on Rust
On Friday, 6 February 2015 at 05:16:56 UTC, Vlad Levenfeld wrote: On Friday, 6 February 2015 at 05:05:08 UTC, Ola Fosheim Grøstad wrote: OT: Have you looked at Ada SPARK 2014 yet? Provides nice and strong system programming language semantics. With a verification tool... nice. http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.html Even more OT: Most of this doc went over my head. Controlled types, access types? I only grok that its meant for safety-critical systems. What's this kind of programming called? And can you recommend any resources for learning about the subject from square one? Access types is Ada speak for pointers. Ada is quite expressive with pointers, as what the developers are allowed to do with them depends on their declaration. Outside the ML languages, Ada is probably the only language that allows for expressing correct programs just by taking care to define the right type abstractions. For example no need to check if a variable is inside a specific range, if the type only allows that range. Or no need to check for null pointers if they are declared as non nullable. It is one of my favourite languages.
Re: D + Solaris
On Friday, 6 February 2015 at 07:05:01 UTC, Suliman wrote: ldc supports solaris/x86 but druntime/Phobos support will most likely be lacking what does it's mean? It is not fully work or what? Where are you quoting that from? If I remember correctly then druntime at least was fully working. I would recommend asking on http://forum.dlang.org/group/digitalmars.D.ldc to get a proper answer as to the extent of the support.
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126
sinkuup...@gmail.com changed:
What|Removed |Added
CC||sinkuup...@gmail.com
--- Comment #8 from sinkuup...@gmail.com ---
It seems FooBar class isn't required.
import core.stdc.stdio;
struct Foo {
private uint _foo = 1;
~this() {
printf(%d\n, _foo);
}
}
void main() {
Foo[] foos;
foos.length = 512;
}
This prints 1 with 2.066.1, but prints 16777216 with 2.067a. On my system,
array length must be = 510 to reproduce the bug.
--
[Issue 14130] New: REG(2.067) Ice following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130
Issue ID: 14130
Summary: REG(2.067) Ice following error in template parameter
default value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: yebbl...@gmail.com
F sumKBN(Range, F = Unqual)(Range r, F s = 0.0)
{
}
void main()
{
0.sumKBN;
}
DMD v2.067 DEBUG
testx.d(7): Error: undefined identifier Unqual
assert template.c(2586) fd-type-ty == Tfunction
--
Re: Wrong pointer calculation without casting on struct
On 02/05/2015 07:59 PM, tcak wrote: writeln( Without: , (this + id.offsetof) ); In pointer arithmetic, the increment value means that many *objects* away, not than many bytes away. Since id.offsetof is 4, you are calculating 4 MessageBase objects away (4*8==32 bytes away). writeln( With : , (cast(size_t)this + id.offsetof) ); That is not pointer arithmetic, so the increment is just 4. 32 - 4 == 28. Ali
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #7 from Rainer Schuetze r.sagita...@gmx.de --- Checking the code from 2.066 again, it corrupts memory - if the array.ptr offset from the base pointer in a small allocation is larger than 15 bytes - if the array.ptr offset from the base pointer in a large allocation is larger than 4095 bytes. So apart from some rather obscure indices above 0, but below some threshold, only passing the array base pointer actually worked. Making other pointers raise an error seems an improvement. For a partial length, it didn't make much of a difference unless struct destructors have to be called. Not calling all of them is very probably an error, too. Informing the user about this with an error should be ok. This leaves the case when a wrong size didn't cause any issues. An error could be considered annoying, so maybe we could relax option 3 a little for types without destructor. --
Re: @trust is an encapsulation method, not an escape
On 2/6/15 11:29 AM, Zach the Mystic wrote: The best evidence I have it that everyone who actually worked on the phobos code you disapprove of says it's a problem. I see more like two. -- Andrei
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 17:50:05 UTC, Tobias Pankrath wrote:
I was referring to a hypothetical untrusted block that might
be used something like this:
---
void foo(Range)(Range r) @trusted {
// ...
untrusted {
r.front;
}
// Your manually checked code.
untrusted {
r.popFront;
}
// …
}
---
Using current semantics we must not mark foo @trusted, if
r.front and
r.popFront aren't. Using the proposed @safe-blocks (are those
untrusted blocks the same?) we could guarantee that, by
wrapping the use of r.front and r.popFront in @safe-blocks.
This is limiting because now we cannot provide an foo marked
@system for all @system ranges without boiler plate or
duplicating the function.
Correct?
Yes.
The untrusted blocks were an ad-hoc invention to show how @safe
blocks could be modified to actually work in this case (for
template functions, don't require @safe, but mark the function
@system if the contents are unsafe), but that this modification
results in a much less desirable design than just straight up
having @trusted blocks.
David
Re: Renaming DMD File Extensions from C to C++
On Thursday, 5 February 2015 at 09:03:40 UTC, ketmar wrote: On Wed, 04 Feb 2015 21:45:01 +, deadalnix wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? If I make a PR to make these file cpp, what are the chances for it to be accepted ? git is capable of tracking renaming, so it should create any conflict. it's moving things for the sake of moving things. i hope that don't move things for nothing is the universal rule. i hate fixing all my scripts and links. Well you are talking for talking, we are waiting on your awesome PRs.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 3:57 AM, Martin Krejcirik wrote:
If I understand it correctly, Walter is against adding trusted blocks (trusted
{...}) into @safe functions. But what about having safe blocks in @trusted
functions ?
int somefunc() @trusted
{
int a = systemfunc();
int b;
@safe {
b = safefunc(); // calling systemfunc() not allowed;
}
return a + b;
}
The problem is, again:
@trusted code must have a safe interface
and with code blocks, there is no interface specified to them other than
examining EVERY line of code in it.
The way interfaces are specified in D is to use functions.
Re: @trust is an encapsulation method, not an escape
On 2/6/15 12:36 PM, Atila Neves wrote:
I'm trying to promote suggesting '@system' blocks instead of
'@trusted'. '@trusted' functions, but '@system' blocks - which can
only go in @trusted functions (@system block in @system functions are
redundant). It's the same semantics, but it might win the day because
the intent is to isolate the @system code, while still presenting a
@trusted interface, as seems so important to the leadership.
That might be better than using @safe inside @trusted:
@trusted void myfunc() {
//implicitly safe
@system { //wouldn't compile otherwise.
auto ptr = cast(ubyte*)4;
}
//implicitly safe again
}
BTW, this is H.S. Teoh's suggestion too, and I like it better than mine
after much thought.
-Steve
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic wrote: It's been suggested that '@system' be used to mark the blocks in question. The point would be to emphasize the dangerousness of the operation. The function is still @trusted, but inside, the @system code is marked as such. This is precisely equivalent to just making the function @safe and using @trusted blocks inside (which is incidentally my preferred approach, and similar to what parts of Phobos try to emulate). As I argued almost three years ago in my @trusted considered harmful post, @trusted doesn't differ in meaning from @safe for API clients. Both mean that you can call the function from @safe code, nothing more, nothing less. I hope we agree on that. You might argue that having @trusted in the function declaration serves as an indicator that the implementation requires extra careful review. However, there will *still* be a @trusted keyword sitting in the source code and staring at your face even with @trusted blocks. And if you don't have the source code for a function you call to begin with, all bets are off anyway (i.e. you need to trust its author) as @safe functions may always internally call @trusted ones. If the leadership feels that your proposal is to be preferred because it keeps @trusted in the function signature (as he correctly remarked, the safety of @trusted blocks might depend on surrounding @safe code), then so be it. However, it makes an implementation detail part of the API (see @trusted considered harmful), and furthermore is not backwards-compatible. David
Arrays of Unions of Classes?
I'm just wondering how I would go about reserving a section of the heap so I can have linear access to classes of different types. Storage space--not too worried about wasting; each class I want to store only has a few int sized variables each and I'm not going to cry over a little padding. Because classes are reference types, does that mean a union or an array would only hold a reference to that class? Is there a way for them to be squished up next to each other in a way that'd make iterating over them efficent? I could do this with structs (at least I think I can in D) except they're not polymorphic and structs don't remember their type internally like classes do when inside unions (I just tested this, I assume it's a feature not a bug?). I have a lot of elements in an array that I need to pass over constantly so if I can not break them up and not have to make up pretend internal polymorphism with switch statements inside functions then that'd both make my code look less like spaghetti and leave room for me to bog down my program with other crap. How do I do this in D?
Re: Zero-length static array spec
On 6 February 2015 at 16:33, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 1 February 2015 at 15:34:48 UTC, Iain Buclaw wrote: Regardless of size, a static array should always have an address on the stack. Of course, dereferencing said address is undefined. You can also consider it a require that although a zero-length static array may have an address, it doesn't take up any space either. Consider: int[0] data0; int[1] data1; Here, you could expect both data0 and data1 to have the same .ptr address, but data0.ptr == data1.ptr should not succeed either. Let's have a look at a related example: int[0] data0; int[0] data1; assert(data0.ptr != data1.ptr); // ??? If you want this assert to succeed, how do you ensure that the addresses are different without allocating at least one byte of stack space (which currently seems to be prohibited by the does not take up space clause). For debugging purposes, it must have a position on the stack pointer. For semantic purposes, comparing it as being equal to another value must be false.
Re: Arrays of Unions of Classes?
On 02/06/2015 10:55 AM, DLearner wrote: I can have linear access to classes of different types To be pedantic, you mean *objects* of different types. (Class is the type.) Because classes are reference types, does that mean a union or an array would only hold a reference to that class? Yes. Is there a way for them to be squished up next to each other in a way that'd make iterating over them efficent? I have an example of doing exactly that on a single hierarchy here: http://ddili.org/ders/d.en/memory.html#ix_memory.emplace,%20class As seen in that example, you still need to walk through references to the actual objects. If your classes do not belong to the same hierarchy then you have to maintain some kind of type identification yourself. Ali
Re: @trust is an encapsulation method, not an escape
On 2/6/15 2:16 PM, Andrei Alexandrescu wrote: On 2/6/15 11:11 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/6/15 10:42 AM, David Nadlinger wrote: On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote: It's clear. I just don't think it's a good point. -- Andrei I'm not making a point; I'm posing a problem. What is your solution? I think the problem is overstated. -- Andrei This is precisely why I have lost all interest in @safe. It's clear that the present problematic situation will continue to hold, and the decision makers are not interested to address it. I am not going to waste any more time and energy on this topic. I've asked repeatedly for evidence of the problematic situation, and all I got was doomsday predictions maintenance nightmare!. If you have such, please show it. If not, thanks for a good course of action. -- Andrei I think your strawman is overstated. The doomsday is the current situation to which you and Walter have objected. If you think having better discipline in reviews is going to fix it, I guess we will have to wait and see what the evidence eventually does show. There isn't evidence that either solution has worked, because neither has been employed yet. Logically, it makes sense to me that we should adjust how @trusted operates to prevent preventable problems that you have identified. But we can just keep the status quo and rely on manual process improvements instead. It's not terribly important to fix it right now, we can try your way first, I don't see how adjusting the meaning of @trusted in the future would be any more disruptive than it would be now. If this is how it is to be, can we get some guidelines as to what should and should not pass review for @trusted? -Steve
strange work of GC
class C1
{
int a1, b1, c1, d1, e1;
string sdb1;
this(string s)
{
sdb1 = s;
a1=90;
b1=19;
d1=22;
e1=23;
}
~this()
{
if (sdb1 == lll)
{
sdb1 = aaa;
}
writeln(disposing ~sdb1);
}
}
class C2
{
C1 c1 = null;
int a2, b2, c2, d2, e2;
string sdb2;
this(string s)
{
sdb2 = s;
a2=90;
b2=19;
d2=22;
e2=23;
}
~this()
{
c1=null;
writeln(disposing ~sdb2);
}
};
void fn1()
{
writeln(start of fn1);
C2[] arr = new C2[1_000_000];
for (int i=0; iarr.length; i++)
{
arr[i] = new C2(text(i, C2 class creation));
arr[i].c1 = new C1(text(i, C1 class creation));
}
writeln(end of fn1);
}
void main(string[] args)
{
fn1();
bool b = true
while(b == true)
{
Thread.sleep(dur!(msecs)(5));
}
}
This code never starts the garbage collector, but after execution
fn1 nothing refers to arr.
As I think, the garbage collector should start destoying of the
C1 and C2 objects of arr array during the while cycle prosess,
but this does not
happen. Dtors are not called.
If I use the manual destroying of objects C1 and C2 by destroy
method, the dtors of C1 and C2 objects are normally called, but
it can't be safe.
If I use the GC.collect method after fn1, I get an error:
core.exception.InvalidMemoryOperationError@(0).
Is this a bug of GC or I do something wrong?
Thanks.
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134
--- Comment #5 from Rainer Schuetze r.sagita...@gmx.de ---
Maybe we should relax the restriction on base pointers for free().
What should happen with code like this?
struct S { ~this() { printf(~this\n); } int x; }
S[] arr = new S[1000];
S[] slice = arr[100..200];
S[] tail = arr[200..1000];
delete slice;
Should it call call only 100 destructors? All 1000? Is this invalid code?
Calling dtors twice could be fixed by explicitely removing the FINALIZE
attribute from the block, but could not work for just a part of the array.
--
Re: @trust is an encapsulation method, not an escape
On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/6/15 10:42 AM, David Nadlinger wrote: On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote: It's clear. I just don't think it's a good point. -- Andrei I'm not making a point; I'm posing a problem. What is your solution? I think the problem is overstated. -- Andrei This is precisely why I have lost all interest in @safe. It's clear that the present problematic situation will continue to hold, and the decision makers are not interested to address it. I am not going to waste any more time and energy on this topic. T -- Question authority. Don't ask why, just do it.
Re: Google Summer of Code - Again
On Fri, 2015-02-06 at 14:15 +, CraigDillabaugh via Digitalmars-d wrote: A note on QML bindings. Filippo, the creator of DOtherSide, the QML bindings, expressed some interest in participating the 2015 GSOC. However time may be an issue for him. Russel Winder, if you are reading, would you be willing to co-mentor with Filippo if he feels he needs (and would like) the help? I'm entirely happy to be backup mentor for this. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: @trust is an encapsulation method, not an escape
On 2/6/15 3:02 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer wrote: I see the point now that making sure @safe functions don't have escapes has the advantage of not requiring *as much* review as a @system or @trusted function. I am leaning so much towards H.S. Teoh's solution of making @trusted safe by default, and allowing escapes into @system code. That seems like the right abstraction. Just to make sure that I got this right: I don't really understand why you need to escape to @system from @trusted. Isn't @trusted the same as @system but with a seal that says that it has been manually verified to be memory safe? @system simply allows the same internal semantics as @trusted but with no such declared guarantee to the caller? In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes. I don't have any time to read your further points, but I will catch up with them later, sorry! -Steve
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 4:17 AM, Kagamin wrote:
On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
On 2/6/2015 12:31 AM, Kagamin wrote:
On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
static void trustedMemcopy(T[] dest, T[] src) @trusted
{
assert(src.length == dest.length);
memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
}
Should be enforce: assert doesn't guard against malicious usage.
Cue my endless attempts to explain the difference between input errors and
logic errors :-(
A little offtop: if this function is compiled in release mode and compiler
assumes assert holds, it's free to use dest.length instead of src.length and if
at runtime dest is longer than src, this will create heartbleed-like bug in safe
code.
Sigh. Please visit your nearest Catholic school and ask one of the nuns to
thwack your knuckles with a ruler!
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 18:58:27 UTC, David Nadlinger wrote: On Friday, 6 February 2015 at 17:13:09 UTC, Zach the Mystic wrote: It's been suggested that '@system' be used to mark the blocks in question. The point would be to emphasize the dangerousness of the operation. The function is still @trusted, but inside, the @system code is marked as such. This is precisely equivalent to just making the function @safe and using @trusted blocks inside (which is incidentally my preferred approach, and similar to what parts of Phobos try to emulate). No it's not. Forcing @trusted functions, with @system blocks inside builds a redundancy into the system. Now someone from outside the can read the signature and know there might be a problem, and someone inside can find everywhere that problem could possibly have arisen from. The difference is you now have two signals instead of one - one in the function header, and the other(s) in the code itself. As I argued almost three years ago in my @trusted considered harmful post, @trusted doesn't differ in meaning from @safe for API clients. Both mean that you can call the function from @safe code, nothing more, nothing less. I hope we agree on that. I know. This was recently pointed out again by Steven Schveighoffer, and it's a great insight. You might argue that having @trusted in the function declaration serves as an indicator that the implementation requires extra careful review. However, there will *still* be a @trusted keyword sitting in the source code and staring at your face even with @trusted blocks. And if you don't have the source code for a function you call to begin with, all bets are off anyway (i.e. you need to trust its author) as @safe functions may always internally call @trusted ones. It is a redundancy, yes, but one people might actually *appreciate*. People around here take memory safety very seriously, and probably with good reason! If the leadership feels that your proposal is to be preferred because it keeps @trusted in the function signature (as he correctly remarked, the safety of @trusted blocks might depend on surrounding @safe code), then so be it. However, it makes an implementation detail part of the API (see @trusted considered harmful), and furthermore is not backwards-compatible. It's not backward-compatible, but it's not hard to fix at all. You get an error, and you enclose your unsafe code in a @system block. And the quality of your code improves at the same time. The only reason the implementation detail, @trusted, was made part of the API was precisely because memory safety is taken extremely seriously by the language designers. There's no other reason I can think of, but for some reason, I can appreciate the thought. Also, I want to find a real solution and I doubt anyone is suggesting getting rid of @trusted at this point.
signal handling
Hi, if I want to clean up inside a signal handler and then exit the process (as it would have without me handling it), what do I do? Can I exit() inside a signal handler or should I use a more direct quit now function? (after all, it could have been in the middle of relinking the free list when the signal arrived) Do I reinstall the previous signal handler and then abort() ? If I want to store the previous signal handler, do I have to store in a shared variable ? If I have multiple threads, what will happen to the other threads? Will it join() them and hang or will it kill them as well or will it just stop the thread that received the signal? Which thread did receive the signal?
Re: @trust is an encapsulation method, not an escape
On 2/6/15 11:53 AM, Steven Schveighoffer wrote: I think your strawman is overstated. The doomsday is the current situation to which you and Walter have objected. I see that just as: code in poor style made its way in Phobos. It doesn't improve anything (e.g. didn't find bugs in std.file.read) and is just a net negative resulting from the corrupted use of a feature. There's no completely automated protection against poor style. If you think having better discipline in reviews is going to fix it, I guess we will have to wait and see what the evidence eventually does show. There isn't evidence that either solution has worked, because neither has been employed yet. Logically, it makes sense to me that we should adjust how @trusted operates to prevent preventable problems that you have identified. But we can just keep the status quo and rely on manual process improvements instead. It's not terribly important to fix it right now, we can try your way first, I don't see how adjusting the meaning of @trusted in the future would be any more disruptive than it would be now. If this is how it is to be, can we get some guidelines as to what should and should not pass review for @trusted? Wise words. Walter has a PR on docs, you may want to review it: https://github.com/D-Programming-Language/dlang.org/pull/890 Andrei
Re: strange work of GC
On Friday, 6 February 2015 at 20:38:07 UTC, Andrey Derzhavin wrote: As I think, the garbage collector should start destoying of the C1 and C2 objects of arr array during the while cycle prosess, but this does not happen. Dtors are not called. Garbage is only collected when you allocate memory. You're just `sleep`ing in the loop which doesn't allocate anything, and so it doesn't trigger garbage collections. If I use the manual destroying of objects C1 and C2 by destroy method, the dtors of C1 and C2 objects are normally called, but it can't be safe. right If I use the GC.collect method after fn1, I get an error: core.exception.InvalidMemoryOperationError@(0). Is this a bug of GC or I do something wrong? This is you GC allocating in a destructor (the writeln calls). The GC can't handle that.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 5:13 AM, Vladimir Panteleev wrote: So, to repeat my question: which one is it? Have you changed your mind, or are there exceptions to the rules in the post you quoted? It means that you, the programmer, have to decide whether it is environmental input validation or a logic error in your code. Follow the rules: 1. exceptions are not for debugging the logic of your program 2. do not use exceptions to recover from logic bugs in your program I have pontificated on this at GREAT length in multiple threads in this n.g. If it is still a mystery to you or anyone else, I give up. Keep in mind the levels of expertise: newbie: follow the rules because you're told they're the right thing to do master: follow the rules because you understand they're the right thing to do guru: transcend the rules because you know when they don't apply
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote: It seems obvious that explicitly whitelisting a small number of potentially dangerous but safe operations is much less error-prone approach than disabling compiler checks for everything and then having to remember to blacklist all unverified external dependencies. David That seems obvious to me too. Isn't the whole purpose of having '@trusted' in the first place to direct a programmer who's having memory safety problems to the potential sources those problems? But why have this and then stop at the function level? Why not force the programmer to tag precisely those portions of his code which cause him to tag his function @trusted to begin with? Why help him get to the function, and then leave him hanging out to dry once inside the function?
Re: @trust is an encapsulation method, not an escape
On 2/6/15 10:36 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Friday, 6 February 2015 at 15:10:18 UTC, Steven Schveighoffer wrote: into suspect the whole function. So marking a function @safe, and having it mean this function has NO TRUSTED OR SYSTEM CODE in it whatsoever, is probably the right move, regardless of any other changes. But that would break if you want to call a @safe function with a @trusted function reference as a parameter? Or did I misunderstand what you meant here? The whole point of marking a function trusted instead of a block is that you have to follow the rules of function calling to get into that block, and your separate function only has access to variables you give it. My point was that if you have @trusted escapes inside a function, whether it's marked @safe or not, you still have to review the whole function. If the compiler disallowed this outright, then you don't have that issue. Separating the trusted code from the safe code via an API barrier has merits when it comes to code review. Now, @trusted static nested functions that stand on their own are fine, they are no different than public ones, just not public. @trusted static nested functions that are ONLY OK when called in certain ways, that is where we run into issues. At that point, you have to make a choice -- add (somewhat unnecessary) machinery to make sure the function is always called in a @safe way, or expand the scope of the @trusted portion, possibly even to the whole @safe function. I see the point now that making sure @safe functions don't have escapes has the advantage of not requiring *as much* review as a @system or @trusted function. I am leaning so much towards H.S. Teoh's solution of making @trusted safe by default, and allowing escapes into @system code. That seems like the right abstraction. And... what happens if you bring in a new architecture that requires @trusted implementation of a library function that is @safe on other architectures? Then you create a @trusted wrapper around that API, ensuring when called from @safe code it can't corrupt memory. 1. A way to say this function needs extra scrutiny 2. Mechanical verification as MUCH AS POSSIBLE, and especially for changes to said function. Yes, we can do 2 manually if necessary. But having a compiler that never misses on pointing out certain bad things is so much better than not having it. I am not sure if it is worth the trouble. If you are gonna conduct a semi formal proof, then you should not have a mechanical sleeping pillow that makes you sloppy. ;-) I see what you mean, but there are also really dumb things that people miss that a compiler won't. Having a mechanical set of eyes in addition to human eyes is still more eyes ;) Also if you do safety reviews they should be separate from the functional review and only focus on safety. Maybe it would be interesting to have an annotation for @notprovenyet, so that you could have regular reviews during development and then scan the source code for @trusted functions that need a safety review before you a release is permitted? That way you don't have to do the safety review for every single mutation of the @trusted function. The way reviews are done isn't anything the language can require. Certainly we can provide guidelines, and we can require such review processes for phobos and druntime. -Steve
Re: @trust is an encapsulation method, not an escape
On 2/6/15 10:42 AM, David Nadlinger wrote: On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote: It's clear. I just don't think it's a good point. -- Andrei I'm not making a point; I'm posing a problem. What is your solution? I think the problem is overstated. -- Andrei
Changing extension file from c to cpp in dmd
https://github.com/D-Programming-Language/dmd/pull/4382 This has been a recurrent request. Considering how things are going, it won't get in. Make your voice heard or do not complain about it in the future. D won't make any progress with this talk but do not act attitude. If you want something but aren't even prepared to defend it when other are doing the work for you, you are wasting everybody's time by posting here.
Re: Another idiom I wish were gone from phobos/druntime
On Friday, 6 February 2015 at 16:22:00 UTC, ketmar wrote:
On Fri, 06 Feb 2015 15:59:04 +, Chris wrote:
Hm. But the compiler can check, if the signature is ok. E.g.
wtf, compiler, are you making fun of me? you KNOW what i mean,
yet you
insisting that i have to please you... ah, fsck it! that shitty
feature
never worth it anyway.
auto foo (int n) { ... }
auto foo (int n, int m) { ... }
// i'm s sleepy
contract {
auto foo (int n) {
...
}
auto foo (int n, int m) {
...check for foo(n) that i copipasted here
...and completely forgot about it, 'cause
...that contract clause is so far away
...from the function itself...
}
}
and so on.
I like it, if things can be put aside in blocks, like unittest
or debug.
unittest and debug blocks are not parts of function contract,
that's why
they can be separated. they are merely *checks*, not
*prerequisites*.
I would like to try, if it is really so bad. If laziness is an
argument against it, it also applies to in {} and out {}, doesn't
it?
Re: Arrays of Unions of Classes?
On Friday, 6 February 2015 at 18:55:30 UTC, DLearner wrote: I'm just wondering how I would go about reserving a section of the heap so I can have linear access to classes of different types. Storage space--not too worried about wasting; each class I want to store only has a few int sized variables each and I'm not going to cry over a little padding. Because classes are reference types, does that mean a union or an array would only hold a reference to that class? Is there a way for them to be squished up next to each other in a way that'd make iterating over them efficent? I could do this with structs (at least I think I can in D) except they're not polymorphic and structs don't remember their type internally like classes do when inside unions (I just tested this, I assume it's a feature not a bug?). I have a lot of elements in an array that I need to pass over constantly so if I can not break them up and not have to make up pretend internal polymorphism with switch statements inside functions then that'd both make my code look less like spaghetti and leave room for me to bog down my program with other crap. How do I do this in D? Let's say you have a class with name MyClass. You create an array with that: MyClass[64] myClassList; Then you have created objects in this array: myClassList[0] = new MyClass(); myClassList[1] = new MyClass(); myClassList[2] = new MyClass(); ... Now you have linear access to objects in this array: myClassList[2].setIntValue( 7 ); What is the necessity for these objects in heap to be consecutive?
Re: DlangIDE
On Friday, 6 February 2015 at 17:44:04 UTC, Vadim Lopatin wrote: On Friday, 6 February 2015 at 15:17:53 UTC, Chris wrote: On Friday, 6 February 2015 at 14:43:02 UTC, Vadim Lopatin wrote: On Friday, 6 February 2015 at 14:32:24 UTC, Chris wrote: On Friday, 6 February 2015 at 14:03:07 UTC, Vadim Lopatin wrote: Hello, I'm working on cross-platform D language IDE - DlangIDE. It's written in D using DlangUI based GUI. Project on GitHub: https://github.com/buggins/dlangide ... .dub/build/application-debug-linux.posix-x86_64-dmd_2066-B4CC9A972252F02EBBDEC316D316367F/ dlangide executable Error executing command run: dmd failed with exit code 1. Looks like older version of dlangui is used. Please try `dub upgrade` This one worked for me, however, it has to be $ dub upgrade --force-remove else you get this message: Upgrading project in /home/christoph/D/dlangide Re-installing branch based dependency derelict-ft ~master Error executing command upgrade: Untracked file found, aborting package removal, file: /home/name/.dub/packages/derelict-ft-master/lib/libDerelictFT.a Please remove the package folder manually or use --force-remove. Great stuff! Looks very promising. It definitely needs more features on the editing side of things (shift left/right, line comment, block comment). Maybe it would be good to have snippets too. Especially for ranges and other D idioms that are commonly used. Shift left/right: tab / shift+tab Comment/uncomment: will add soon. What is best shortcut for it? Ctrl+/ is my favorite (for line comments) Other important features: - delete line - duplicate line - format block, i.e. select code and all the indentation levels will be put right (jEdit has a great automatic indentation functionality). - highlight matching brackets and braces - highly configurable behavior (again jEdit is very good there too) I'll come up with more suggestions next week. Now it's weekend
Re: @trust is an encapsulation method, not an escape
On 2/6/15 11:11 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Feb 06, 2015 at 10:52:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/6/15 10:42 AM, David Nadlinger wrote: On Friday, 6 February 2015 at 18:39:28 UTC, Andrei Alexandrescu wrote: It's clear. I just don't think it's a good point. -- Andrei I'm not making a point; I'm posing a problem. What is your solution? I think the problem is overstated. -- Andrei This is precisely why I have lost all interest in @safe. It's clear that the present problematic situation will continue to hold, and the decision makers are not interested to address it. I am not going to waste any more time and energy on this topic. I've asked repeatedly for evidence of the problematic situation, and all I got was doomsday predictions maintenance nightmare!. If you have such, please show it. If not, thanks for a good course of action. -- Andrei
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 19:16:13 UTC, Andrei Alexandrescu wrote: This is precisely why I have lost all interest in @safe. It's clear that the present problematic situation will continue to hold, and the decision makers are not interested to address it. I am not going to waste any more time and energy on this topic. I've asked repeatedly for evidence of the problematic situation, and all I got was doomsday predictions maintenance nightmare!. If you have such, please show it. If not, thanks for a good course of action. -- Andrei The best evidence I have it that everyone who actually worked on the phobos code you disapprove of says it's a problem. Argumentum ad populem, I know, but it calls for close scrutiny, to say the least. My attitude is not based on evidence. It's based on just thinking about the problem: http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org I really can't answer this question.
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #8 from Rainer Schuetze r.sagita...@gmx.de --- Other notes: - The current version also works for memory allocated outside the GC, it just doesn't free the memory. - The current version works for manually allocated arrays (e.g. Appender). So if the code stays as it is, our promoted method of destroying an array is no good. There is no good way to destroy an array except delete. What is the proposed method? Using GC.free(arr.ptr)? --
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer wrote: My point was that if you have @trusted escapes inside a function, whether it's marked @safe or not, you still have to review the whole function. If the compiler disallowed this outright, then you don't have that issue. Ok, I also prefer that @trusted only apply to whole functions. I don't agree with the argument, but let's leave it at that ;-). Separating the trusted code from the safe code via an API barrier has merits when it comes to code review. Yes. And I actually don't think @trusted functions in Phobos should contain version() or other forms for conditional compilation since that makes it much harder to reason about. I see the point now that making sure @safe functions don't have escapes has the advantage of not requiring *as much* review as a @system or @trusted function. I am leaning so much towards H.S. Teoh's solution of making @trusted safe by default, and allowing escapes into @system code. That seems like the right abstraction. Just to make sure that I got this right: I don't really understand why you need to escape to @system from @trusted. Isn't @trusted the same as @system but with a seal that says that it has been manually verified to be memory safe? @system simply allows the same internal semantics as @trusted but with no such declared guarantee to the caller? Except that in @system you could potentially switch the stacks and do other unsafe operations that are not brought back to normal before leaving the system context... In @trusted you are required to restore the context to normal before returning. So in the type system you only have @safe and @system, @trusted is just @safe with flexible manual verification rather than the limited automated verification DMD is capable of. Thus you only need to export @safe vs @system for separate compilation...? Isn't that how it is supposed to work already? I see what you mean, but there are also really dumb things that people miss that a compiler won't. Having a mechanical set of eyes in addition to human eyes is still more eyes ;) Well, if you can come up with something sound. The way I see it, @trusted functions are allowed to create a new context on entry as long as it restores the previous context before exiting. This essentially means that what is @safe before entering @trusted no longer can be guaranteed to be safe. The floating point unit might work differently and result in memory unsafe operations etc etc. So calling @safe from @trusted means that you are calling @safe as if it was @system. And therefore @safe code called from @trusted has to be proven correct just like @system code called from @trusted. The way reviews are done isn't anything the language can require. Certainly we can provide guidelines, and we can require such review processes for phobos and druntime. Yes, in Phobos you need to impose additional stricter guarantees in order to support the formal review process and ensure that the formal review cannot be broken without a new review taking place. And yes, that is a process requirement, not a language requirement. A different process might impose other requirements... I think you will have to define such a process though, because I don't think there is a solution for fully automated verification for D without going for a much more complex type system and mechanics (which I actually think is out of reach unless everything is designed around it). Fortunately with 3 reviewers you can do quite well if the proof is available and they work independently without sharing results before everyone is done. If each reviewer has a 10% chance of failure then you end up with only 0.1% chance of all of them failing... So it is possible to get decent results with a formal process in place. Complicated @trusted code (hard to prove safe) should be rejected and unnecessary @trusted code should be fixed in the compiler optimizer or by adding language features (like SIMD).
Re: strange work of GC
On Friday, 6 February 2015 at 20:38:07 UTC, Andrey Derzhavin wrote: As I think, the garbage collector should start destoying of the C1 and C2 objects of arr array during the while cycle prosess, but this does not happen. Dtors are not called. The D GC only runs on demand - typically, when you allocate new memory is when the gc might run. This keeps totally hidden pauses from happening, so you at least can avoid a collection at a bad time for your program. If I use the GC.collect method after fn1, I get an error: core.exception.InvalidMemoryOperationError@(0). Is this a bug of GC or I do something wrong? You used GC memory from inside a destructor. That's an illegal operation; read the tip of the week from Sunday's newsletter to see a bit more: http://arsdnet.net/this-week-in-d/feb-01.html
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer
wrote:
In the proposal, @trusted code is actually considered the same
as @safe, but allows @system escapes.
But that can't work:
@trusted_is_safe {
auto tmp = get_hardware_config();
@system{
mess_up_hardware_config();
}
// now this unsafe call is called in a @safe context, but is
unsafe...
// DMD does not catch this, so @trusted_is_safe is broken
call_safe_code_that_now_is_messed_up();
@system{
restore_hardware_config(tmp);
}
}
Re: strange work of GC
On Friday, 6 February 2015 at 21:07:14 UTC, anonymous wrote: This is you GC allocating in a destructor (the writeln calls). The GC can't handle that. Note that it isn't writeln itself, it is the ~ used in building the string. If you change that to a comma, it'll work better (writeln can take multiple arguments and avoid allocating an intermediate string (sometimes))
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 7:48 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Then how is this more work than implementing something like a linear type system that is both tedious for the programmer and has taken Rust 8 years to get into working shape...? Rust has unsafe blocks with specific instructions that it cannot be verified mechanically and it is up to the programmer to ensure a safe interface to it. So no, Rust didn't get that working, either, and it is far beyond current compiler technology to do it.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 7:14 AM, Wyatt wrote: The current @trusted semantics (and accompanying politics) make it exceedingly clear that @safe is meaningless for anything beyond trivial, one-off tools that will never receive maintenance. You are correct in how @trusted is currently (mis)used in Phobos. We aim to fix this. @trusted must provide a safe interface. No exceptions. Yes, that requires review of @trusted code by someone who thoroughly understands this, but there's no other way.
Re: Zero-length static array spec
On 6 February 2015 at 22:16, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 6 February 2015 at 19:10:01 UTC, Iain Buclaw wrote: For debugging purposes, it must have a position on the stack pointer. This sentence does not parse for me. on the stack *pointer*? For semantic purposes, comparing it as being equal to another value must be false. That's not clear to me from the spec. One could argue that a zero-byte entity can by definition not have an identity. In any case, my question was how to implement that behavior without allocating memory, which the spec currently prohibits. David Simple, you implement it by allocating no memory. :) I'll have to see what goes on, I can't imagine that llvm won't provide some way to do this. GDC's behaviour is incident in the backend rather than intent. Iain.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote: This is precisely why I have lost all interest in @safe. It's clear that the present problematic situation will continue to hold, and the decision makers are not interested to address it. I am not going to waste any more time and energy on this topic. In this thread at 8:20PM last night, Dicebot asked me: I am not even sure how you can show the example though, to be honest - implied issues are about maintaining code and not just writing it. And I replied with a specific example of how to fix one aspect of std.array. There have been no replies. What else can I do to address it?
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote: Rust has unsafe blocks with specific instructions that it cannot be verified mechanically and it is up to the programmer to ensure a safe interface to it. So no, Rust didn't get that working, either, and it is far beyond current compiler technology to do it. Rust guarantees, though, that all code outside of unsafe blocks/functions is completely safe, which D doesn't do because of trusted. I think that `unsafe` in Rust is more like @trust in D, but I'm not completely sure about that.
Re: Google Summer of Code - Again
On Friday, 6 February 2015 at 19:34:53 UTC, Russel Winder wrote: On Fri, 2015-02-06 at 14:15 +, CraigDillabaugh via Digitalmars-d wrote: A note on QML bindings. Filippo, the creator of DOtherSide, the QML bindings, expressed some interest in participating the 2015 GSOC. However time may be an issue for him. Russel Winder, if you are reading, would you be willing to co-mentor with Filippo if he feels he needs (and would like) the help? I'm entirely happy to be backup mentor for this. Thanks.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 2:39 PM, Meta wrote: On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote: Rust has unsafe blocks with specific instructions that it cannot be verified mechanically and it is up to the programmer to ensure a safe interface to it. So no, Rust didn't get that working, either, and it is far beyond current compiler technology to do it. Rust guarantees, though, that all code outside of unsafe blocks/functions is completely safe, which D doesn't do because of trusted. I think that `unsafe` in Rust is more like @trust in D, but I'm not completely sure about that. Rust guarantees no such thing, because it is explicitly up to the Rust programmer to verify a safe interface to unsafe code blocks. It is no different from the D @trusted programmer verifying a safe interface to @trusted code.
[Issue 14135] std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 --- Comment #1 from David Nadlinger c...@klickverbot.at --- Source permalink for your convenience: https://github.com/D-Programming-Language/phobos/blob/041db2d8fac2b1cf5169be7188ea537a01f27586/std/uuid.d#L1061-L1086 --
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 3:02 PM, Zach the Mystic wrote: No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions. This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough. My evidence for this is how @trusted was used in Phobos.
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 10:58 AM, David Nadlinger wrote: @trusted doesn't differ in meaning from @safe for API clients. Both mean that you can call the function from @safe code, nothing more, nothing less. I hope we agree on that. That is correct. @trusted is a statement about the implementation of a function, not its interface. This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code. Hence, I view it as the best compromise to make @trusted also apply only at the function level.
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote: No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions. Also, to be clear, any @system block inside a @safe function is an automatic error.
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 21:56:40 UTC, Walter Bright wrote:
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just
thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this question.
You asked:
Why not force the programmer to tag precisely those portions
of his code
which cause him to tag his function @trusted to begin with?
That question has been asked and answered repeatedly. The
answer is that @trusted is not only to TAG unsafe code, but
must provide a SAFE INTERFACE to it.
@trusted {
... unsafe code ...
}
provides no indication of what the interface to the unsafe code
is. Addressing only the TAG aspect is insufficient.
No, at least three of us, Steven, H.S. Teoh and myself have
confirmed that we've moved beyond requesting @trusted blocks. We
are no longer requesting them. We are requesting *@system*
blocks, which can only appear in @trusted and @system functions.
Any unsafe code appearing in a @trusted function which is not
inside a @system block is an error. We've changed the name, but I
think it will make a world of difference regarding how you will
look at it. Marking '@system' code inside a @trusted function is
exactly what is requested. Your message about '@trusted' being
only acceptable as an interface has been heard. There will be no
@trusted blocks, only @system blocks, which are the exact same
thing, except they can only appear in @trusted and @system
functions.
This solution appeals to me greatly. It pinpoints precisely where
unsafe code can generate; it catches unintended safety violations
in all @trusted code outside @system blocks, as requested by many
people so far; it makes systems programming highly visible, with
redundancy at the function signature and at the unsafe code
itself. I really think it's spot on!
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 8:19 AM, John Colvin wrote: Is that what we want? I can't see why not, but it feels off somehow... Effectively you've got @trusted blocks in an @trusted function, just inverted. Right. It just inverted the interface problem, the problem remains. So, no for this idea. Another way to say it: @safe = @trusted must go through a safe interface @trusted = @safe must go through a safe interface
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 11:29 AM, Zach the Mystic wrote:
My attitude is not based on evidence. It's based on just thinking about the
problem:
http://forum.dlang.org/post/eeglnychgudcffpjc...@forum.dlang.org
I really can't answer this question.
You asked:
Why not force the programmer to tag precisely those portions of his code
which cause him to tag his function @trusted to begin with?
That question has been asked and answered repeatedly. The answer is that
@trusted is not only to TAG unsafe code, but must provide a SAFE INTERFACE to it.
@trusted {
... unsafe code ...
}
provides no indication of what the interface to the unsafe code is. Addressing
only the TAG aspect is insufficient.
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote: In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes. That seems like a good idea and in the spirit of what the goal is. However, won't it be a breaking change?
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 5:28 AM, Steven Schveighoffer wrote: It's better because I know where it is used. It's used in one place, and I can squash it right there saying No, you can't do this in this one place. Instead of reviewing an API in ALL POSSBILE CONTEXTS (which if trustedCast is a public API, would be a lot), I have to review one call in ONE CONTEXT. The former is WORSE because it can be used in 100 places. Now I have to go through and fix ALL THOSE FUNCTIONS that use it, because its interface was exposed to the whole of phobos. This is the crux of the problem - failing to define a safe interface to the trusted code block. Without defining an interface, you're right, you must review all the context(s) that call it. With a safe interface you DO NOT. You only have to review the interface. A simple rule: If you need to do a safety review on the context in which @trusted code is called YOU ARE DOING IT WRONG because you've failed to provide a safe interface to the @trusted code. It's like solving a physics problem and winding up with negative energy. If that happens, you made a mistake. It is not a matter of judgement or opinion, it is an objective fact. Going forward, all @trusted code that leaks unsafety into its context will be rejected for inclusion in Phobos. The code reviewer only has to review the @trusted block to determine this - he does not have to review the context.
Re: Git, the D package manager
On Thursday, 5 February 2015 at 09:00:05 UTC, Atila Neves wrote: On Thursday, 5 February 2015 at 06:46:12 UTC, weaselcat wrote: After reading this thread I think I'm the only person here who actually likes makefiles. Nothing ever feels as complete as a good old hand written makefile. Assuming you get it right. In my experience, this is analogous to saying nothing ever feels as complete as manually managing memory. Humans shouldn't write Makefiles. As in the case of managing memory, I used to do that (hand-write Makefiles). I don't anymore because the alternatives are far better. Atila And just as manual memory management, human must be able to manage it manually when required. Not in the general case, not as the default, but as a possibility. This is what is wrong with most other build systems.
Re: Zero-length static array spec
On Friday, 6 February 2015 at 19:10:01 UTC, Iain Buclaw wrote: For debugging purposes, it must have a position on the stack pointer. This sentence does not parse for me. on the stack *pointer*? For semantic purposes, comparing it as being equal to another value must be false. That's not clear to me from the spec. One could argue that a zero-byte entity can by definition not have an identity. In any case, my question was how to implement that behavior without allocating memory, which the spec currently prohibits. David
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote: This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! Even a call to a @system function inside a @trusted function must occur inside a @system block. It's that strict.
The outcome of DIP73 discussion – D Programming Language Labs
Hi, Because there is no strong evidence that DIP73 would fly, I had to take some modification to initial plan. Firstly I needed a workaround for the blocking point (creating an official repository) on my implementation list. In result I created a satellite project at: https://github.com/D-Programming-Language-Labs The main goals remain sill the same: Speed up the development of standard modules by uniting majority of D developers Lower the commitment barrier and attract more contributors Provide out of the box and batteries included experience All with emphasis on collaborative work and being in line with the official D development. And I ask all of you to resolve the following two issues: 1. I presume that a part of the community don't want me to spam the main D development forum, so I have a question how to handle further discussion related to the idea? Can I temporary use some other unused forum (e.g. digitalmars.empire) to carry out the initial phase of the project? 2. What's the best choice for codename of the drafting library: - Mars - (I think Walter should comment if it's not reserved for the language itself) - Curiosity – I like it more (reference to the Mars Science Laboratory ) but I don't now what's the native English speakers perception of using the “curiosity” word in this context. - Other Piotrek
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote: I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough. My evidence for this is how @trusted was used in Phobos. How is adding @system to some operations *in addition to* adding @trusted to the function declaration more likely to lull people into a false sense of security than just adding @trusted right now? Let me also point out that the cases where the @system block equivalent is used right now (like in std.file, or the trustedXyz functions in std.array) are NOT the ones that actually have safety bugs in them (such as std.array.uninitializedArray or std.uuid.randomUUID). The two latter examples were actually written in your preferred style. David
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote: This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough. My evidence for this is how @trusted was used in Phobos. You do realize that our proposal *tightens* security, with no loosening at all? No code which currently fails to compile will start compiling with this proposal. This is literally a breaking change which does nothing but cause errors in existing code - for the explicit purpose of making all code safer, which it will do, possibly dramatically.
Re: Zero-length static array spec
On Friday, 6 February 2015 at 23:37:30 UTC, Iain Buclaw wrote:
Simple, you implement it by allocating no memory. :)
Let me put it a different way. Imagine you have this in your
program:
---
void foo() {
int[0] a0;
int[0] a1;
...
int[0] a99;
// Do something with them.
}
---
How do you choose the addresses for a0 through a99 so that they
are distinct, but you don't end up allocating 100 bytes of stack
memory?
David
Re: misplaced @trust?
On 2/6/2015 8:10 AM, Andrei Alexandrescu wrote: On 2/6/15 3:26 AM, Tobias Pankrath wrote: I'd like D to provide the following guarantee: If I corrupt my memory using @safe code, the error must be in code marked @trusted / @system, either because the do not provide a @safe interface or because they are buggy. That's what we're going for. -- Andrei Exactly. And it's been that way all along.
Re: Special Type Challenge
On Saturday, 7 February 2015 at 01:55:27 UTC, Jonathan Marler
wrote:
b = -256;
that won't fit in a byte btw.
The rest of the assignment stuff is easy. I'd prolly even do it
with a template:
this(T)(T t) { this.opAssign(t); } // for construction
Byte opAssign(T)(T t) if(T.sizeof == 1) { // for other assignment
data_holder = cast(typeof(data_holder) t);
}
and that should do it.
Byte[] barr;
barr = teststring;
barr = [0,1,2,3];
}
Language won't let you do these though.
Re: Special Type Challenge
On Saturday, 7 February 2015 at 03:48:24 UTC, Adam D. Ruppe wrote:
wrote:
b = -256;
that won't fit in a byte btw.
Woops, I typed that example too fast :)
The rest of the assignment stuff is easy. I'd prolly even do it
with a template:
this(T)(T t) { this.opAssign(t); } // for construction
Byte opAssign(T)(T t) if(T.sizeof == 1) { // for other
assignment
data_holder = cast(typeof(data_holder) t);
}
and that should do it.
This code is almost exactly what I came up with. But what about
the function problem?
void echo(Byte b);
echo('c'); // won't work
I can't figure out a way to make this work (without making echo a
template). If D supported implicit conversions from built-in
types to user types then it could work. Do you know if D might
support that later or if there's a reason for not supporting it?
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 01:43:01 UTC, Andrei Alexandrescu
wrote:
With the system proposal we're looking at something like:
version (Posix) void[] read(in char[] name, size_t upTo =
size_t.max) @trusted
{
import core.memory;
// A few internal configuration parameters {
enum size_t
minInitialAlloc = 1024 * 4,
maxInitialAlloc = size_t.max / 2,
sizeIncrement = 1024 * 16,
maxSlackMemoryAllowed = 1024;
// }
@system
{
immutable fd =
core.sys.posix.fcntl.open(name.tempCString(),
core.sys.posix.fcntl.O_RDONLY);
}
cenforce(fd != -1, name);
scope(exit) core.sys.posix.unistd.close(fd);
stat_t statbuf = void;
@system
{
cenforce(trustedFstat(fd, trustedRef(statbuf)) == 0,
name);
}
immutable initialAlloc = to!size_t(statbuf.st_size
? min(statbuf.st_size + 1, maxInitialAlloc)
: minInitialAlloc);
void[] result = uninitializedArray!(ubyte[])(initialAlloc);
scope(failure) delete result;
size_t size = 0;
for (;;)
{
@system
{
immutable actual = core.sys.posix.unistd.read(fd,
result.ptr + size),
min(result.length, upTo) - size);
}
cenforce(actual != -1, name);
if (actual == 0) break;
size += actual;
if (size result.length) continue;
immutable newAlloc = size + sizeIncrement;
@system
{
result = GC.realloc(result.ptr, newAlloc,
GC.BlkAttr.NO_SCAN)[0 .. newAlloc];
}
@system
{
return result.length - size = maxSlackMemoryAllowed
? GC.realloc(result.ptr, size,
GC.BlkAttr.NO_SCAN)[0 .. size]
: result[0 .. size];
}
}
We want to move D forward, folks. This is not it.
Andrei
Oh I see. There are three posts, in the latter two of which the
little @trusted functions are already removed. I had thought they
were all identical, but you obviously realized the little
functions should be removed.
Re: Renaming DMD File Extensions from C to C++
On Fri, 06 Feb 2015 18:48:16 +, deadalnix wrote: Well you are talking for talking, we are waiting on your awesome PRs. easy deal. and i'm waiting for Andrei and Walter preapprovement. i'm not interested in writing code for nothing. ah, and forbidding patch attachements to bugzilla. i'm still waiting for my $25 bounty, code for which keeps rotting there. signature.asc Description: PGP signature
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 9:49 PM, Vladimir Panteleev wrote: On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright wrote: 1. exceptions are not for debugging the logic of your program 2. do not use exceptions to recover from logic bugs in your program OK, this is nothing new, but still doesn't answer my question. You wrote is clearly a program bug. Therefore use assert(). It's as simple as that.
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: SublimeLinter D Plugin
On Friday, 6 February 2015 at 13:58:13 UTC, Andrej Mitrovic wrote: Do we have a Sublime plugin based on D-Scanner which gives us some features like: - List all methods in a class - Hide (or just fold) non-public methods of a class And other similar features? No, because you haven't written it yet.
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 01:41:19 UTC, Andrei Alexandrescu
wrote:
Consider the previous code:
[...]
static trustedRead(int fildes, void* buf, size_t nbyte)
@trusted
{
return core.sys.posix.unistd.read(fildes, buf, nbyte);
}
static trustedRealloc(void* p, size_t sz, uint ba = 0,
const TypeInfo ti = null) @trusted
{
return GC.realloc(p, sz, ba, ti);
}
static trustedPtrAdd(void[] buf, size_t s) @trusted
{
return buf.ptr+s;
}
static trustedPtrSlicing(void* ptr, size_t lb, size_t ub)
@trusted
{
return ptr[lb..ub];
}
First of all, these little @trusted functions are made obsolete
by the new system. They should certainly be omitted.
@system
{
immutable fd =
core.sys.posix.fcntl.open(name.tempCString(),
core.sys.posix.fcntl.O_RDONLY);
}
Next, you have to realize that @system blocks are like 'try'
blocks: You don't need brackets if there's only one statement in
them.
Here's how I would rewrite what you have written using the new
method:
version (Posix) void[] read(in char[] name, size_t upTo =
size_t.max)
@trusted
{
import core.memory;
// A few internal configuration parameters {
enum size_t
minInitialAlloc = 1024 * 4,
maxInitialAlloc = size_t.max / 2,
sizeIncrement = 1024 * 16,
maxSlackMemoryAllowed = 1024;
// }
@system immutable fd =
core.sys.posix.fcntl.open(name.tempCString(),
core.sys.posix.fcntl.O_RDONLY);
cenforce(fd != -1, name);
scope(exit) core.sys.posix.unistd.close(fd);
stat_t statbuf = void;
@system cenforce(trustedFstat(fd, trustedRef(statbuf)) == 0,
name);
immutable initialAlloc = to!size_t(statbuf.st_size
? min(statbuf.st_size + 1, maxInitialAlloc)
: minInitialAlloc);
void[] result = uninitializedArray!(ubyte[])(initialAlloc);
scope(failure) delete result;
size_t size = 0;
for (;;)
{
@system immutable actual = core.sys.posix.unistd.read(fd,
result.ptr + size, min(result.length, upTo) -
size);
cenforce(actual != -1, name);
if (actual == 0) break;
size += actual;
if (size result.length) continue;
immutable newAlloc = size + sizeIncrement;
@system result = GC.realloc(
result.ptr, newAlloc, GC.BlkAttr.NO_SCAN)[0 ..
newAlloc];
}
@system return result.length - size = maxSlackMemoryAllowed
? GC.realloc(result.ptr, size,
GC.BlkAttr.NO_SCAN)[0..size]
: result[0 .. size];
}
Note that I just mechanically your @system blocks with the better
form. I didn't arrange for them to be elegant. There's nothing
wrong with encapsulating a @trusted sequence in a @system block
with brackets, to aid future reviewers in identifying subsequent
code thought to be affected by the @system statements. Also, few
functions will have their @system blocks more or less evenly
distributed throughout like the above function does.
The new proposal will never let you add an unsafe operation
without your knowing it. It's definitely the way forward.
Re: why GC not work?
On Sat, 07 Feb 2015 04:30:07 +, Safety0ff wrote:
False pointers, current GC is not precise.
not only that. constantly allocating big chunks of memory will inevitably
lead to OOM due to current GC design. you can check it with manual
freeing. there were some topics about it, and the solution is either use
64 bit OS ('cause the memory is here, but there is no address space to
allocate it), or use `malloc()` and `free()` from libc.
signature.asc
Description: PGP signature
Re: Another idiom I wish were gone from phobos/druntime
On Fri, 06 Feb 2015 19:09:47 +, Chris wrote:
I would like to try, if it is really so bad. If laziness is an argument
against it, it also applies to in {} and out {}, doesn't it?
it's not lazyness per se, it's inconsistency and lack of usability. sure,
you are free to try, but i bet that you simply waste some time with it. i
have nothing personal against this (i simply don't care).
signature.asc
Description: PGP signature
Fast array copy. SIMD manual or automatic?
I have two char arrays at the size of 16KB. I will copy a part of data between them again and again. arrayA[0 .. dataLen] = arrayB[0 .. dataLen]; Does the compiler generate code that uses SIMD operations (128-bits memory copy) automatically, or do I need to do anything special for this?
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic wrote: Note that I just mechanically your @system blocks with the better form. ...mechanically replaced, I mean, of course.
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 21:08:21 UTC, Walter Bright wrote: 1. exceptions are not for debugging the logic of your program 2. do not use exceptions to recover from logic bugs in your program OK, this is nothing new, but still doesn't answer my question. Would you say that the correct thing to do, then, would be an unconditional check that throws an Error? Such as, `if (!...) throw new Error(...)`, or `enforce!Error(...)`? I recall there is a bug report on Bugzilla that Phobos contracts are removed in release (default) builds of the library, when ideally contracts of public functions should stay but inner asserts should be removed in optimized code. That would allow using them for validating parameters without resorting to explicitly-unconditional checks.
Re: @trust is an encapsulation method, not an escape
On Saturday, 7 February 2015 at 05:35:51 UTC, Zach the Mystic wrote: Here's how I would rewrite what you have written using the new method: ... stat_t statbuf = void; @system cenforce(trustedFstat(fd, trustedRef(statbuf)) == 0, name); I didn't rewrite this because I didn't see the trustedXXX functions they referred to, but the basic rewrite would be: @system cenforce(fstat(fd, reff(statbuf) == 0), name); In other words, just copy the @system code directly without going through @trusted.
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e5f21beb82acade73900aa50a0e092b3935e980b fix Issue 13952 - change in struct ctor lowering triggers codegen bug https://github.com/D-Programming-Language/dmd/commit/2ebb60303208768adfa29d29f11f7fc8c95fffa7 Merge pull request #4387 from 9rnsr/fix13952 [REG2.067a] Issue 13952 - change in struct ctor lowering triggers codegen bug --
why GC not work?
import std.stdio;
void testGC()
{
auto b = new byte[](1024*1024*100);
writeln(malloc 100M!);
}
void main()
{
foreach(i;1..100)
{
testGC();
}
}
--
core.exception.OutOfMemoryError@(0)
win7 x86,dmd v2.066.0
Re: why GC not work?
False pointers, current GC is not precise.
Re: Special Type Challenge
On 2/6/15 8:28 PM, Jonathan Marler wrote: Do you know if D might support that later or if there's a reason for not supporting it? It's deliberate following the C++ experience. -- Andrei
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Summary|std.uuid.randomUUID |std.uuid.randomUUID breaks |violates breaks @safety |@safety --
Special Type Challenge
I'm wondering if the following is possible in D. I tried and
failed but maybe someone else will be able to pull it off.
// Challenge: Create a type named Byte that,
// 1. Uses 1 byte of memory
// 2. Can be used as an argument to a non-template function
// 3. Handles implicit conversion from any 1-byte type
// 4. Compiles and passes the following unittest
unittest
{
Byte b;
b = 0;
b = 1;
b = 255;
b = -256;
b = 'a';
b = cast(const char)'a';
b = cast(immutable char)'a';
b = cast(byte)1;
b = cast(const byte)1;
b = cast(immutable byte)1;
b = cast(ubyte)1;
b = cast(const ubyte)1;
b = cast(immutable ubyte)1;
Byte echo(Byte b)
{
return b;
}
b = echo('a');
b = echo(cast(const char)'a');
b = echo(cast(immutable char)'a');
b = echo(cast(byte)1);
b = echo(cast(const byte)1);
b = echo(cast(immutable byte)1);
b = echo(cast(ubyte)1);
b = echo(cast(const ubyte)1);
b = echo(cast(immutable ubyte)1);
Byte[] barr;
barr = teststring;
barr = [0,1,2,3];
}
Re: Special Type Challenge
On Saturday, 7 February 2015 at 01:55:27 UTC, Jonathan Marler
wrote:
Byte b;
b = 0;
b = 1;
b = 255;
b = -256;
b = 'a';
b = cast(const char)'a';
b = cast(immutable char)'a';
b = cast(byte)1;
b = cast(const byte)1;
b = cast(immutable byte)1;
b = cast(ubyte)1;
b = cast(const ubyte)1;
b = cast(immutable ubyte)1;
These are possible with opAssign (which should be accompanied
with corresponding constructor(s)).
Byte echo(Byte b)
{
return b;
}
b = echo('a');
b = echo(cast(const char)'a');
b = echo(cast(immutable char)'a');
b = echo(cast(byte)1);
b = echo(cast(const byte)1);
b = echo(cast(immutable byte)1);
b = echo(cast(ubyte)1);
b = echo(cast(const ubyte)1);
b = echo(cast(immutable ubyte)1);
Byte[] barr;
barr = teststring;
barr = [0,1,2,3];
}
These are not possible as D does not support implicit
construction.
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 21:33:01 UTC, Walter Bright wrote: On 2/6/2015 10:58 AM, David Nadlinger wrote: @trusted doesn't differ in meaning from @safe for API clients. Both mean that you can call the function from @safe code, nothing more, nothing less. I hope we agree on that. That is correct. @trusted is a statement about the implementation of a function, not its interface. This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code. Hence, I view it as the best compromise to make @trusted also apply only at the function level. Please see this post: http://forum.dlang.org/post/riphxcqazksykafum...@forum.dlang.org
[Issue 14135] New: std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 Issue ID: 14135 Summary: std.uuid.randomUUID violates breaks @safety Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: major Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: c...@klickverbot.at The @trusted UUID randomUUID(RNG)(ref RNG randomGen) if(isIntegral!(typeof(RNG.front))) overload is incorrectly marked as @trusted, as the user might pass a custom RNG with @system range primitives. Seems like it was introduced in https://github.com/D-Programming-Language/phobos/pull/1708. --
Re: @trust is an encapsulation method, not an escape
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote: No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions. This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on! this sounds interesting, is anyone going to make a DIP for it?
[Issue 14135] std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Keywords||safe --
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 3:34 PM, David Nadlinger wrote: On Friday, 6 February 2015 at 23:25:02 UTC, Walter Bright wrote: I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough. My evidence for this is how @trusted was used in Phobos. How is adding @system to some operations *in addition to* adding @trusted to the function declaration more likely to lull people into a false sense of security than just adding @trusted right now? Let me also point out that the cases where the @system block equivalent is used right now (like in std.file, or the trustedXyz functions in std.array) are NOT the ones that actually have safety bugs in them (such as std.array.uninitializedArray or std.uuid.randomUUID). The two latter examples were actually written in your preferred style. I've said that the usage of those functions was not actually buggy, what was wrong about them was that they required review of the surrounding supposedly safe context. I.e. they produced a false sense of safety. I fear the @system blocks, even if only allowed in @trusted functions, would produce a similar illusion of safety. I agree with Andrei in that I do not believe that reviewing a @trusted function, line by line, for safety is necessarily some sort of maintenance nightmare. If it is, then a refactoring should be considered to encapsulate the unsafe code in a smaller, simpler manner. I.e. let's make an effort to use @trusted correctly, and then see where we stand. Scott Meyer's excellent article (a classic): http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 describes this most eloquently. (Just substitute private members with trusted code.)
Re: @trust is an encapsulation method, not an escape
On Fri, Feb 06, 2015 at 04:04:48PM -0800, Walter Bright via Digitalmars-d wrote: [...] I agree with Andrei in that I do not believe that reviewing a @trusted function, line by line, for safety is necessarily some sort of maintenance nightmare. If it is, then a refactoring should be considered to encapsulate the unsafe code in a smaller, simpler manner. [...] This does not take into the account the fact that a @trusted function may call other, non-@trusted, functions. When one of those other functions changes, the @trusted function necessarily needs to be reviewed again. However, under the current implementation, this is not done because when the other, non-@trusted, function is modified, nobody thinks to re-review the @trusted function. They may not even be in the same module. There is no mechanism in place to raise a warning flag when a @trusted function's dependencies are modified. Thus, the proof of safety of the @trusted function has been invalidated, but trust continues to be conferred upon it. T -- Let's call it an accidental feature. -- Larry Wall
Re: @trust is an encapsulation method, not an escape
On 2/6/2015 4:29 PM, H. S. Teoh via Digitalmars-d wrote: This does not take into the account the fact that a @trusted function may call other, non-@trusted, functions. When one of those other functions changes, the @trusted function necessarily needs to be reviewed again. That's correct. However, under the current implementation, this is not done because when the other, non-@trusted, function is modified, nobody thinks to re-review the @trusted function. They may not even be in the same module. There is no mechanism in place to raise a warning flag when a @trusted function's dependencies are modified. Thus, the proof of safety of the @trusted function has been invalidated, but trust continues to be conferred upon it. When the interface to an @system function is changed, all uses of that function have to be reviewed, whether one thinks of it or not. This is part of the review process. Having @system blocks does not alter that.
[Issue 14137] New: std.socket.getAddressInfo breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14137
Issue ID: 14137
Summary: std.socket.getAddressInfo breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
const(char[]) convert() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return null;
}
alias convert this;
}
void main() @safe {
import std.socket;
getAddressInfo(, Oops.init);
}
---
Seems to be Git master (to-be 2.067) only.
Source permalink:
https://github.com/D-Programming-Language/phobos/blob/master/std/socket.d#L996-L997
Introduced in https://github.com/D-Programming-Language/phobos/pull/2316.
--
[Issue 14138] New: std.parallelism.task breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14138
Issue ID: 14138
Summary: std.parallelism.task breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
int convert() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return 0;
}
alias convert this;
}
void main() @safe {
import std.parallelism;
static void foo(int) @safe {}
auto t = task(foo, Oops.init);
// or: auto t = scopedTask(foo, Oops.init);
taskPool.put(t);
}
---
Tested with current Git master (4de96a06, to-be 2.067), but looks like the
issues has been present since the initial merge of std.parallelism.
Again a case of @trusted used on a template function without sufficient
constraints.
--
Re: @trust is an encapsulation method, not an escape
On 2/6/15 3:21 PM, weaselcat wrote:
On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
No, at least three of us, Steven, H.S. Teoh and myself have confirmed
that we've moved beyond requesting @trusted blocks. We are no longer
requesting them. We are requesting *@system* blocks, which can only
appear in @trusted and @system functions. Any unsafe code appearing in
a @trusted function which is not inside a @system block is an error.
We've changed the name, but I think it will make a world of difference
regarding how you will look at it. Marking '@system' code inside a
@trusted function is exactly what is requested. Your message about
'@trusted' being only acceptable as an interface has been heard. There
will be no @trusted blocks, only @system blocks, which are the exact
same thing, except they can only appear in @trusted and @system
functions.
This solution appeals to me greatly. It pinpoints precisely where
unsafe code can generate; it catches unintended safety violations in
all @trusted code outside @system blocks, as requested by many people
so far; it makes systems programming highly visible, with redundancy
at the function signature and at the unsafe code itself. I really
think it's spot on!
this sounds interesting, is anyone going to make a DIP for it?
Consider the previous code:
https://github.com/D-Programming-Language/phobos/blob/accb351b96bb04a6890bb7df018749337e55eccc/std/file.d#L194
that got replaced with:
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L194
With the system proposal we're looking at something like:
version (Posix) void[] read(in char[] name, size_t upTo = size_t.max)
@trusted
{
import core.memory;
// A few internal configuration parameters {
enum size_t
minInitialAlloc = 1024 * 4,
maxInitialAlloc = size_t.max / 2,
sizeIncrement = 1024 * 16,
maxSlackMemoryAllowed = 1024;
// }
@system
{
immutable fd = core.sys.posix.fcntl.open(name.tempCString(),
core.sys.posix.fcntl.O_RDONLY);
}
cenforce(fd != -1, name);
scope(exit) core.sys.posix.unistd.close(fd);
stat_t statbuf = void;
@system
{
cenforce(trustedFstat(fd, trustedRef(statbuf)) == 0, name);
}
immutable initialAlloc = to!size_t(statbuf.st_size
? min(statbuf.st_size + 1, maxInitialAlloc)
: minInitialAlloc);
void[] result = uninitializedArray!(ubyte[])(initialAlloc);
scope(failure) delete result;
size_t size = 0;
for (;;)
{
@system
{
immutable actual = core.sys.posix.unistd.read(fd,
result.ptr + size),
min(result.length, upTo) - size);
}
cenforce(actual != -1, name);
if (actual == 0) break;
size += actual;
if (size result.length) continue;
immutable newAlloc = size + sizeIncrement;
@system
{
result = GC.realloc(result.ptr, newAlloc,
GC.BlkAttr.NO_SCAN)[0 .. newAlloc];
}
@system
{
return result.length - size = maxSlackMemoryAllowed
? GC.realloc(result.ptr, size, GC.BlkAttr.NO_SCAN)[0 .. size]
: result[0 .. size];
}
}
We want to move D forward, folks. This is not it.
Andrei
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
I've been using this for learning experience and tried to use .jpg for the Image Object in vain. Are there plans to include jpg support here? Or is there a workaround for that? or can I use other image libraries to embed it to a Label Object or Button Object?
[Issue 14136] New: std.uni.utfMatcher breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14136
Issue ID: 14136
Summary: std.uni.utfMatcher breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
pure:
bool empty() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return true;
}
Oops save() @property { return this; }
char front;
void popFront() {}
char back;
void popBack() {}
ref char opIndex(size_t idx) { return front; }
enum size_t length = 0;
alias opDollar = length;
}
void main() @safe {
import std.uni;
auto m = utfMatcher!char(unicode.Number);
Oops o;
m.match(o);
}
---
Again, the reason is a @trusted template function taking an arbitrary range.
Source permalink (other match variants are affected too):
https://github.com/D-Programming-Language/phobos/blob/041db2d8fac2b1cf5169be7188ea537a01f27586/std/uni.d#L4767-L4787
Introduced in https://github.com/D-Programming-Language/phobos/pull/2020.
--
[Issue 14138] std.parallelism.task breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14138 David Nadlinger c...@klickverbot.at changed: What|Removed |Added Severity|enhancement |major --
Re: Special Type Challenge
On Saturday, 7 February 2015 at 02:12:08 UTC, Jakob Ovrum wrote:
Byte echo(Byte b)
{
return b;
}
b = echo('a');
b = echo(cast(const char)'a');
b = echo(cast(immutable char)'a');
b = echo(cast(byte)1);
b = echo(cast(const byte)1);
b = echo(cast(immutable byte)1);
b = echo(cast(ubyte)1);
b = echo(cast(const ubyte)1);
b = echo(cast(immutable ubyte)1);
Byte[] barr;
barr = teststring;
barr = [0,1,2,3];
}
These are not possible as D does not support implicit
construction.
It's a bit odd that D supports implicit conversions from
user-defined types to built-in types but not the reverse. What's
the reason for this? Is it done on purpose or is this just a
hole that might be filled in later?
