View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2013
Re: Incorporating D
On 1/26/2013 1:41 AM, Johannes Pfau wrote:
> IIRC toStringz is also dangerous. You have to make sure that the C
> library does not store the pointer or also store it manually so the GC
> can find it. (This is not different from passing other C/D pointers, but
> with toStringz it's easy to miss).

That's not a bug in the GC, though.
January 26, 2013
Re: Incorporating D
On Saturday, January 26, 2013 10:41:46 Johannes Pfau wrote:
> Am Fri, 25 Jan 2013 22:38:51 +0100
> 
> schrieb "Jonathan M Davis" <jmdavisProg@gmx.com>:
> > On Friday, January 25, 2013 22:33:14 q66 wrote:
> > > > D's GC does not have serious problems. The only issue is
> > > > controversial status of GC.
> > > 
> > > D's GC has inherent issues with false positives, sometimes
> > > freeing memory that you don't really want freed, causing
> > > (sometimes hidden) bugs that are pretty much impossible to debug.
> > 
> > I've _never_ heard of it freeing something when it shouldn't.
> 
> I've seen that when porting GDC. Usually happens if the GC fails to
> scan the stack or more often it misses some TLS ranges. Never saw that
> with dmd though.
> 
> IIRC toStringz is also dangerous. You have to make sure that the C
> library does not store the pointer or also store it manually so the GC
> can find it. (This is not different from passing other C/D pointers, but
> with toStringz it's easy to miss).

Which is why the toStringz documentation points that out. The GC can only see 
what's referred to in the D code, not C code, so you have to make sure that 
the D code retains a reference to any pointers passed into C code or risk the 
GC thinking that it's okay to free it. But there really isn't any way around 
that, and it's completely different from the GC incorrectly thinking that a 
pointer was not referenced anywhere in D code and freeing it.

- Jonathan M Davis
January 26, 2013
Re: Incorporating D
Am Sat, 26 Jan 2013 02:19:02 -0800
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> > 
> > IIRC toStringz is also dangerous. You have to make sure that the C
> > library does not store the pointer or also store it manually so the
> > GC can find it. (This is not different from passing other C/D
> > pointers, but with toStringz it's easy to miss).
> 
> Which is why the toStringz documentation points that out. The GC can
> only see what's referred to in the D code, not C code, so you have to
> make sure that the D code retains a reference to any pointers passed
> into C code or risk the GC thinking that it's okay to free it. But
> there really isn't any way around that, and it's completely different
> from the GC incorrectly thinking that a pointer was not referenced
> anywhere in D code and freeing it.
> 
> - Jonathan M Davis

Yes, I just wanted to point out a common source for such bugs, it's not
the GC's fault. It's great that the documentation of toStringz mentions
that issue. What I meant is most of the time we use toStringz() like
this:

string str;
c_function(str.toStringz());

This is only valid if c_function doesn't store the pointer, but newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.
January 26, 2013
Re: Incorporating D
> As he apparently is on Windows, you can only do this with a D 
> DLL, which are likely to be a PITA (but at least they should 
> work unlike on un*x); you can't really link D object files and 
> C/C++ object files together, as on win32 OMF is used

Couldn't you work around that by compiling your D code with 
GDC/MinGW and the C++ code with MinGW?
January 26, 2013
Re: Incorporating D
On 26.01.2013 11:40, Johannes Pfau wrote:
> Yes, I just wanted to point out a common source for such bugs, it's not
> the GC's fault. It's great that the documentation of toStringz mentions
> that issue. What I meant is most of the time we use toStringz() like
> this:
>
> string str;
> c_function(str.toStringz());
>
> This is only valid if c_function doesn't store the pointer, but newbies
> might miss that and just copy this nice looking example code for other
> c functions. There's nothing we can do about that though, interfacing
> to C just is a little bit dangerous.
>

It is even dangerous if it is only used temporarily during that function 
call, but copied elsewhere in the C heap and cleared on the stack:

struct param_struct { const char* name; };

void c_function(const char*p)
{
	param_struct* ps = new param_struct;
	ps->name = p;
	p = 0;
	doSomething(ps);
	delete ps;
}

Imagine a garbage collection while executing doSomething...
January 26, 2013
Re: Incorporating D
On Saturday, 26 January 2013 at 02:51:41 UTC, Namespace wrote:
>> We better get this right and not hurry about this.
>
> I will open a new, separate thread about this tomorrow. Seems 
> to me more appropriate. Then we can discuss about this 
> important but missing feature in detail.

http://forum.dlang.org/thread/nirfuenixutsbgyrcsla@forum.dlang.org#post-nirfuenixutsbgyrcsla:40forum.dlang.org
January 26, 2013
Re: Incorporating D
On 2013-01-25 23:00, Rob T wrote:

> In fact I find that C++ IDE and editor support is no better, and fails often due
> to the near impossible nature of correctly parsing through C++ code.

I think Xcode on Mac OS X is really good. It uses Clang for parsing the 
code, so if the IDE can't parse the code the compiler can't either.

-- 
/Jacob Carlborg
January 26, 2013
Re: Incorporating D
On 2013-01-25 21:45, Szymon wrote:

> 3) Is it possible to use D on iOS?

The short answer is, no. The longer more detailed answer is, DMD cannot 
output ARM code. That means you need to use LDC or GDC. Don't know how 
good they work, also I don't know the status of the runtime on ARM. Then 
you need to somehow integrate the D compiler in the iOS tool chain.

Except from actually be able to compile for iOS you need some way to 
integrate with Objective-C, if you want to do anything useful. For that 
you have three options:

1. The Objective-C runtime functions are implemented in standard C which 
D can call and link to. It becomes very tedious very fast using this 
approach.

2. Use the Objective-C runtime functions via a bridge that handles all 
type conversions and similar automatically. This causes code bloat due 
to template and virtual methods that cannot be optimized away. On Mac OS 
X we're talking about 60MB for a Hello World application.

3. Make D ABI compatible with Objective-C, i.e. extern (Objective-C). 
Michel Fortin has created a fork of DMD that implements this. He has 
released an alpha version of this fork which do work. Unfortunately the 
code hasn't been update for two to three years.

The most correct approach would be number three.

Objective-C bridge: http://www.dsource.org/projects/dstep
D with support for Objective-C: http://michelf.ca/projects/d-objc/

-- 
/Jacob Carlborg
January 26, 2013
Re: Incorporating D
On 1/26/13 4:23 AM, Oleg Kuporosov wrote:
> On Friday, 25 January 2013 at 23:24:54 UTC, Andrei Alexandrescu wrote:
>
>> Thank you for asking. We have been strongly focused on quality
>> improvement since last year but judging from this thread we need to
>> work more on it (and the derived community sentiment).
>>
>> Andrei
>
> And that is true, during 2012 and by now 1495 bug fixed and closed:
>
> http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-01-01&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&component=DMD&product=D
>
>
> That is just so Awesome! Great thanks to everybody involved!
>
> The bad news is there are still some TDPL bugs:
>
> http://d.puremagic.com/issues/buglist.cgi?keywords=tdpl&query_format=advanced&keywords_type=allwords&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=DMD&product=D
>
>
> These probably would require more attention because TDPL is the _only_
> printed
> source of the language.
> Not so big amount although, so using D per TDPL looks pretty safe.

Also, http://dlang.org/bugstats suggests (red line) a downward trend of 
bugs reported and unfixed. I also played a bit with the chart generator 
and plotted open vs. resolved bugs for the past 365 days: 
http://goo.gl/OX9bo. It seems we're consistently reducing net opened 
issues since November.

Andrei
January 26, 2013
Re: Incorporating D
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze 
wrote:
>
>
> On 26.01.2013 11:40, Johannes Pfau wrote:
>> Yes, I just wanted to point out a common source for such bugs, 
>> it's not
>> the GC's fault. It's great that the documentation of toStringz 
>> mentions
>> that issue. What I meant is most of the time we use 
>> toStringz() like
>> this:
>>
>> string str;
>> c_function(str.toStringz());
>>
>> This is only valid if c_function doesn't store the pointer, 
>> but newbies
>> might miss that and just copy this nice looking example code 
>> for other
>> c functions. There's nothing we can do about that though, 
>> interfacing
>> to C just is a little bit dangerous.
>>
>
> It is even dangerous if it is only used temporarily during that 
> function call, but copied elsewhere in the C heap and cleared 
> on the stack:
>
> struct param_struct { const char* name; };
>
> void c_function(const char*p)
> {
> 	param_struct* ps = new param_struct;
> 	ps->name = p;
> 	p = 0;
> 	doSomething(ps);
> 	delete ps;
> }
>
> Imagine a garbage collection while executing doSomething...

That isn't an issue as the pointer will e found at upper level in 
the stack anyway.
2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home