digitalmars.D - Bug 6186
- Benjamin Thaut (10/10) Oct 02 2013 http://d.puremagic.com/issues/show_bug.cgi?id=6186
- Maxim Fomin (6/16) Oct 02 2013 For me the bug is invalid since out parameter is implicitly ref
- Benjamin Thaut (7/10) Oct 02 2013 In my eyes the bug is clearly not invalid because it caused memory leaks...
- H. S. Teoh (21/34) Oct 02 2013 I agree.
- Benjamin Thaut (15/32) Oct 02 2013 Well thats the problem with volenteer work. People usually pick
- Denis Shelomovskij (7/14) Oct 02 2013 So Kenji rapidly (as often) did
- simendsjo (4/18) Oct 02 2013 Don't think I'll ever stop. Post a bug -> fix within hours. Look
- Kenji Hara (15/25) Oct 02 2013 If the given argument to the out parameter is not correctly initialized
- Benjamin Thaut (5/19) Oct 02 2013 I would also be fine with a out paramter always getting rejected as soon...
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
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 ThautFor 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
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
On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote:Am 02.10.2013 20:23, schrieb Maxim Fomin: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.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
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. :-( TWell 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
02.10.2013 23:03, Benjamin Thaut пишет:Am 02.10.2013 20:56, schrieb H. S. Teoh: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. ShelomovskijOn 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
Oct 02 2013
On Thursday, 3 October 2013 at 06:25:04 UTC, Denis Shelomovskij wrote:02.10.2013 23:03, Benjamin Thaut пишет:Don't think I'll ever stop. Post a bug -> fix within hours. Look at github notifications -> several pulls by Kenji.Am 02.10.2013 20:56, schrieb H. S. Teoh:So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time!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
Oct 02 2013
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
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 HaraI 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