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 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 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:

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
prev sibling next sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
--047d7b3440da22e48004e7c672e5
Content-Type: text/plain; charset=UTF-8

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

--047d7b3440da22e48004e7c672e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>If the given argument to the out parameter is not cor= rectly initialized (eg. void initialized variable), calling dtor for the ar= gument is absolutely unsafe. That&#39;s the reason why my patch was rejecte= d by Walter.</div> <div><br></div><div>Alternative language semantics in my thought is:</div><= div>---</div><div>If an out parameter typed T exists, and<br></div><div>=C2= =A0 1. T has elaborate destructor</div>=C2=A0 2. T.init represents logicall= y invalid object (T is nested struct, and/or T has disable this();)<div> Automatic blit initializing for the out parameter would be unsafe.</div><di= v><br></div><div>So semantic analysis would reject such a out parameter dec= laration.</div><div>---</div><div class=3D"gmail_extra"><br></div><div clas= s=3D"gmail_extra"> But I&#39;m still not sure the rule is enough useful for many cases...</div=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Kenji Hara=

r">&lt;<a href=3D"mailto:code benjamin-thaut.de" target=3D"_blank">code ben= jamin-thaut.de</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id= =3D6186" target=3D"_blank">http://d.puremagic.com/issues/<u></u>show_bug.cg= i?id=3D6186</a><br> <br> This bug is open since two years and nothing has happend so far.<br> <br> If you look at it its really funny:<br> <br> Kenji: Heres a Bug and a fix<br> Walter: I don&#39;t like your fix but I don&#39;t have a better idea<br> Kenji: closes pull request<br> -- silence -- (for over 2 years)<br> <br> We should really find a solution for this problem.<br> <br> Kind Regards<span class=3D""><font color=3D"#888888"><br> Benjamin Thaut<br> </font></span></blockquote></div><br></div></div> --047d7b3440da22e48004e7c672e5--
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
prev sibling next sibling parent "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
prev sibling 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:

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