Dealing with the interior pointers bug

2017-06-21 Thread TheGag96 via Digitalmars-d-learn
I saw this Tip of the Week a while ago (http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind of perplexed at it. It seems like a crazy potential bug... How exactly is the GC implemented that causes this problem to crop up? Does the GC just blindly scan memory until it finds pointers

Re: Dealing with the interior pointers bug

2017-06-21 Thread Adam D. Ruppe via Digitalmars-d-learn
On Wednesday, 21 June 2017 at 15:34:15 UTC, TheGag96 wrote: Could it ever be fixed? Easiest: stick `-m64` in your build. While it is somewhat common in 32 bit, it is very rare in 64 bit. This comes from the fact that D's GC is conservative - if it sees something that *might* be a pointer, i

Re: Dealing with the interior pointers bug

2017-06-21 Thread TheGag96 via Digitalmars-d-learn
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: This comes from the fact that D's GC is conservative - if it sees something that *might* be a pointer, it assumes it *is* a pointer and thus had better not get freed. So is the GC then simply made to be "better-safe-than-sorry" o

Re: Dealing with the interior pointers bug

2017-06-21 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn wrote: > On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: > > This comes from the fact that D's GC is conservative - if it sees > > something that *might* be a pointer, it assumes it *is* a pointer > > and t

Re: Dealing with the interior pointers bug

2017-06-21 Thread ag0aep6g via Digitalmars-d-learn
On 06/21/2017 07:23 PM, H. S. Teoh via Digitalmars-d-learn wrote: Being a systems programming language means you should be able to do things outside the type system (in @system code, of course, not in @safe code), including storing pointers as int values. Any C code that your D program interoper

Re: Dealing with the interior pointers bug

2017-06-21 Thread Cym13 via Digitalmars-d-learn
On Wednesday, 21 June 2017 at 17:11:41 UTC, TheGag96 wrote: On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: This comes from the fact that D's GC is conservative - if it sees something that *might* be a pointer, it assumes it *is* a pointer and thus had better not get freed. S

Re: Dealing with the interior pointers bug

2017-06-22 Thread Russel Winder via Digitalmars-d-learn
On Wed, 2017-06-21 at 10:23 -0700, H. S. Teoh via Digitalmars-d-learn wrote: > […] > > The reason the GC must be conservative is because (1) D is a systems > programming language, and also because (2) D interfaces directly with > C. I think the term "systems programming language" contains no actu

Re: Dealing with the interior pointers bug

2017-06-22 Thread Boris-Barboris via Digitalmars-d-learn
On Thursday, 22 June 2017 at 09:45:09 UTC, Russel Winder wrote: I think the term "systems programming language" contains no actual data, so needs to be retired. In this situation it provides no reason for conservative garbage collection. It means the intent of language designer to let you writ

Re: Dealing with the interior pointers bug

2017-06-22 Thread ag0aep6g via Digitalmars-d-learn
On 06/22/2017 12:34 PM, Boris-Barboris wrote: Everything the language allows to compile is allowed by it's type system, or is a bug in the compiler. No. D is not supposed to be completely verifiable by the compiler. For example, the type system guarantees that immutable data never changes. Bu

Re: Dealing with the interior pointers bug

2017-06-22 Thread Steven Schveighoffer via Digitalmars-d-learn
On 6/21/17 1:23 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn wrote: On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote: This comes from the fact that D's GC is conservative - if it sees something that *mig

Re: Dealing with the interior pointers bug

2017-06-22 Thread Boris-Barboris via Digitalmars-d-learn
On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote: For example, the type system guarantees that immutable data never changes. But the compiler allows you to cast from immutable to mutable and change the data. It's an invalid operation, but the compiler is not expected to catch that for

Re: Dealing with the interior pointers bug

2017-06-22 Thread Cym13 via Digitalmars-d-learn
On Thursday, 22 June 2017 at 18:38:59 UTC, Boris-Barboris wrote: On Thursday, 22 June 2017 at 13:56:29 UTC, ag0aep6g wrote: For example, the type system guarantees that immutable data never changes. But the compiler allows you to cast from immutable to mutable and change the data. It's an inval

Re: Dealing with the interior pointers bug

2017-06-22 Thread Boris-Barboris via Digitalmars-d-learn
On Thursday, 22 June 2017 at 19:11:19 UTC, Cym13 wrote: Here it's the programmer's fault really. You should never use casts in normal code, cast is the ultimate switch to say "Look, I know what I'm doing, so disable all safety, don't try to make sense of it, and let me do my thing. If I'm telli

Re: Dealing with the interior pointers bug

2017-06-22 Thread ag0aep6g via Digitalmars-d-learn
On 06/22/2017 08:38 PM, Boris-Barboris wrote: Casts are part of the type system. Yes, D type system allows invalid operations. It's not the compiler's fault, it's type system's fault. unittest { immutable int a = 4; int* b = cast(int*) &a; *b = 5; assert(*(&a) == 5); as

Re: Dealing with the interior pointers bug

2017-06-23 Thread Russel Winder via Digitalmars-d-learn
On Thu, 2017-06-22 at 18:38 +, Boris-Barboris via Digitalmars-d- learn wrote: > […] > > Casts are part of the type system. Yes, D type system allows  > invalid operations. It's not the compiler's fault, it's type  > system's fault. > […] Well maybe casts should be allowed as they effectively