www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug 6186

reply Benjamin Thaut <code benjamin-thaut.de> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6186

This bug is open since two years and nothing has happend so far.

If you look at it its really funny:

Kenji: Heres a Bug and a fix
Walter: I don't like your fix but I don't have a better idea
Kenji: closes pull request
-- silence -- (for over 2 years)

We should really find a solution for this problem.

Kind Regards
Benjamin Thaut
Oct 02 2013
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 2 October 2013 at 18:06:45 UTC, Benjamin Thaut 
wrote:

 http://d.puremagic.com/issues/show_bug.cgi?id=6186

 This bug is open since two years and nothing has happend so far.

 If you look at it its really funny:

 Kenji: Heres a Bug and a fix
 Walter: I don't like your fix but I don't have a better idea
 Kenji: closes pull request
 -- silence -- (for over 2 years)

 We should really find a solution for this problem.

 Kind Regards
 Benjamin Thaut


For me the bug is invalid since out parameter is implicitly ref 
and it has nothing to do with initialization (you better think 
about it as an assignment). This means there are no reasons to 
call destructor.
Oct 02 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 02.10.2013 20:23, schrieb Maxim Fomin:

 For me the bug is invalid since out parameter is implicitly ref and it
 has nothing to do with initialization (you better think about it as an
 assignment). This means there are no reasons to call destructor.


In my eyes the bug is clearly not invalid because it caused memory leaks 
for me. If you have a struct which is a wrapper to a malloced buffer, 
and you pass it to a function which takes the struct as out parameter, 
the destructor will never be called because the memory will simply be 
reinitialized and the memory will leak. In my eyes this is a clear 
struct lifetime bug.
Oct 02 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote:

 Am 02.10.2013 20:23, schrieb Maxim Fomin:

For me the bug is invalid since out parameter is implicitly ref and
it has nothing to do with initialization (you better think about it
as an assignment). This means there are no reasons to call
destructor.


 
 In my eyes the bug is clearly not invalid because it caused memory
 leaks for me. If you have a struct which is a wrapper to a malloced
 buffer, and you pass it to a function which takes the struct as out
 parameter, the destructor will never be called because the memory will
 simply be reinitialized and the memory will leak. In my eyes this is a
 clear struct lifetime bug.


I agree.

This is one area of D that I'm not very impressed with, actually. It is
a minefield full of hazards.  Once your type has a dtor, you can expect
to run into a lot of similar bugs everwhere -- dtors not getting called
at the right places, can't up them in an AA without hitting bugs,
unclear semantics of when/where/how dtors should be called, unclear
semantics on state of member variables, etc.. Just witness, e.g., the
issues we have with emplace and destroy. I suspect it's because most D
code doesn't use dtors, or only uses them in very limited contexts, so
dtor-related code is not well-tested.

I wish these issues can be addressed with a consistent approach rather
than the current ad hoc approach of "there's a fire here let's put in
this hack to fix it, there's another fire over there but we don't know
what to do so we're just going to ignore it". But it doesn't seem to be
the priority right now. :-(


T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.
Oct 02 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 02.10.2013 20:56, schrieb H. S. Teoh:

 On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote:

 I agree.

 This is one area of D that I'm not very impressed with, actually. It is
 a minefield full of hazards.  Once your type has a dtor, you can expect
 to run into a lot of similar bugs everwhere -- dtors not getting called
 at the right places, can't up them in an AA without hitting bugs,
 unclear semantics of when/where/how dtors should be called, unclear
 semantics on state of member variables, etc.. Just witness, e.g., the
 issues we have with emplace and destroy. I suspect it's because most D
 code doesn't use dtors, or only uses them in very limited contexts, so
 dtor-related code is not well-tested.

 I wish these issues can be addressed with a consistent approach rather
 than the current ad hoc approach of "there's a fire here let's put in
 this hack to fix it, there's another fire over there but we don't know
 what to do so we're just going to ignore it". But it doesn't seem to be
 the priority right now. :-(


 T


Well thats the problem with volenteer work. People usually pick 
something they interrested in. (Kenji beeing an exception to this rule)

The most annoying struct lifetime bug for me is the following:
http://d.puremagic.com/issues/show_bug.cgi?id=8360

I have a rcstring struct that internally ref-counts the string memory. 
Because of this bug I can not write

assert(condition, myFormat("%d", i).str());

because it will explode.

I always have to remember writing:

auto error1 = myFormat("%d", i);
assert(condition, error1.str());

which will work correctly.

Kind Regards
Benjamin Thaut
Oct 02 2013
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
02.10.2013 23:03, Benjamin Thaut пишет:

 Am 02.10.2013 20:56, schrieb H. S. Teoh:

 On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote:


 Well thats the problem with volenteer work. People usually pick
 something they interrested in. (Kenji beeing an exception to this rule)

 The most annoying struct lifetime bug for me is the following:
 http://d.puremagic.com/issues/show_bug.cgi?id=8360


So Kenji rapidly (as often) did
https://github.com/D-Programming-Language/dmd/pull/2620

Let's be astonished by his response time!

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Oct 02 2013
parent "simendsjo" <simendsjo gmail.com> writes:
On Thursday, 3 October 2013 at 06:25:04 UTC, Denis Shelomovskij 
wrote:

 02.10.2013 23:03, Benjamin Thaut пишет:

 Am 02.10.2013 20:56, schrieb H. S. Teoh:

 On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut 
 wrote:


 Well thats the problem with volenteer work. People usually pick
 something they interrested in. (Kenji beeing an exception to 
 this rule)

 The most annoying struct lifetime bug for me is the following:
 http://d.puremagic.com/issues/show_bug.cgi?id=8360


 So Kenji rapidly (as often) did
 https://github.com/D-Programming-Language/dmd/pull/2620

 Let's be astonished by his response time!


Don't think I'll ever stop. Post a bug -> fix within hours. Look 
at github notifications -> several pulls by Kenji.
Oct 02 2013
prev sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
If the given argument to the out parameter is not correctly initialized
(eg. void initialized variable), calling dtor for the argument is
absolutely unsafe. That's the reason why my patch was rejected by Walter.

Alternative language semantics in my thought is:
---
If an out parameter typed T exists, and
  1. T has elaborate destructor
  2. T.init represents logically invalid object (T is nested struct, and/or
T has  disable this();)
Automatic blit initializing for the out parameter would be unsafe.

So semantic analysis would reject such a out parameter declaration.
---

But I'm still not sure the rule is enough useful for many cases...

Kenji Hara

2013/10/3 Benjamin Thaut <code benjamin-thaut.de>


 http://d.puremagic.com/issues/**show_bug.cgi?id=6186<http://d.puremagic.com/issues/show_bug.cgi?id=6186>

 This bug is open since two years and nothing has happend so far.

 If you look at it its really funny:

 Kenji: Heres a Bug and a fix
 Walter: I don't like your fix but I don't have a better idea
 Kenji: closes pull request
 -- silence -- (for over 2 years)

 We should really find a solution for this problem.

 Kind Regards
 Benjamin Thaut
Oct 02 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 02.10.2013 20:43, schrieb Kenji Hara:

 If the given argument to the out parameter is not correctly initialized
 (eg. void initialized variable), calling dtor for the argument is
 absolutely unsafe. That's the reason why my patch was rejected by Walter.

 Alternative language semantics in my thought is:
 ---
 If an out parameter typed T exists, and
    1. T has elaborate destructor
    2. T.init represents logically invalid object (T is nested struct,
 and/or T has  disable this();)
 Automatic blit initializing for the out parameter would be unsafe.

 So semantic analysis would reject such a out parameter declaration.
 ---

 But I'm still not sure the rule is enough useful for many cases...

 Kenji Hara


I would also be fine with a out paramter always getting rejected as soon 
as T has a destructor. For such cases a easy fix would be to just 
replace out with ref. I actually grep-ed my whole codebase and replaced 
all "out" with "ref" because of this bug.
Oct 02 2013