Dealing with the interior pointers bug

[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 actual
data, so needs to be retired. In this situation it provides no reason
for conservative garbage collection.

Interfacing with a foreign language, not just C, does bring problems,
but only if there is a shared address space, or the type system is weak
or allows unions including pointers.

> 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 interoperates with may also potentially do similar things.

Why should any language allow anything outside the type system. Strong
typing means strong typing (*).

> Because of this, the GC cannot simply assume that an int value isn't
> actually a pointer value in disguise, so if that int value happens to
> coincide with an address of an allocated memory block, the only sane
> thing it can do is to assume the worst and assume that the memory is
> still live (via that (assumed) reference).  It's not safe for the GC
> to
> assume that it's merely an int, because if it actually turns out to
> be a
> pointer, then you'll end up with a dangling pointer and the ensuing
> memory corruption, security holes, and so forth.  But assuming that
> the
> value is a pointer is generally harmless -- the memory block just
> doesn't get freed right away, but if the int is mutated afterwards,
> eventually the GC will get around to cleaning it up.

Maybe then the fault is having a weak type system, as any language is
that allows ints to be pointers and vice versa. Maybe type systems
should be strong and all FFI be by value with no references to memory
allowed?

> The only big problem is in 32-bit code, where because of the very
> limited space of pointer values, the chances of a random int value
> coinciding with a valid pointer value is somewhat high, so if you
> have a
> large allocated memory block, the chances of a random int being
> mistaken
> for a reference to the block is somewhat high, so you could
> potentially
> run out of memory due to large blocks not being freed when they could
> be.  Fortunately, though, in 64-bit land the space of pointer values
> is
> generally so large that it's highly unlikely that a random int would
> look like a pointer, so this generally isn't a problem if you're
> using
> 64-bit, which is the case more and more now as vendors are slowly
> phasing out 32-bit support.

If there is a problem for 32-bit there is a problem for 64-bit. If it
is possible it will happen.



(*) OK, this joke probably only works in the UK.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20170622/559e5415/attachment.sig>