January 10, 2013
On Thu, Jan 10, 2013 at 01:50:28AM +0100, Adam D. Ruppe wrote:
> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright wrote:
> >And that is not dereferencing null, it is dereferencing 0x1000000.
> 
> Yes, but it is worth noting that dmd will happily compile that code, even if marked @safe - just because the pointer on the language level is null doesn't mean it is memory safe at the assembly level.
> 
> the generated code with @safe is still just what we'd expect too:
>    3:   31 c0                   xor    eax,eax
>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR [eax+0x100000],0xa

Yeah that's exactly what I was thinking too. To DMD, it's a null pointer dereference. But actually, it's dereferencing something else, because x.fieldName is, in general, *not* null when x is null.

Hmm. This looks like another hole in SafeD? Unless null pointer checks are inserted. (The checks have to be made on x, not x.fieldName, of course.)


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
January 10, 2013
On Thursday, 10 January 2013 at 01:10:06 UTC, H. S. Teoh wrote:
> On Thu, Jan 10, 2013 at 01:50:28AM +0100, Adam D. Ruppe wrote:
>> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright wrote:
>> >And that is not dereferencing null, it is dereferencing 0x1000000.
>> 
>> Yes, but it is worth noting that dmd will happily compile that code,
>> even if marked @safe - just because the pointer on the language
>> level is null doesn't mean it is memory safe at the assembly level.
>> 
>> the generated code with @safe is still just what we'd expect too:
>>    3:   31 c0                   xor    eax,eax
>>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR [eax+0x100000],0xa
>
> Yeah that's exactly what I was thinking too. To DMD, it's a null pointer
> dereference. But actually, it's dereferencing something else, because
> x.fieldName is, in general, *not* null when x is null.
>
> Hmm. This looks like another hole in SafeD? Unless null pointer checks
> are inserted. (The checks have to be made on x, not x.fieldName, of
> course.)
>

That is exactly why my NPE proposal do trigger on other address that 0. Still, it require to add check for big objects (or high indices in arrays).
January 10, 2013
On Wednesday, 9 January 2013 at 23:53:40 UTC, Andrei Alexandrescu wrote:
> On 1/9/13 3:38 PM, Paulo Pinto wrote:
>> My favorite GC book:
>>
>> http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484/ref=sr_1_2?s=books-intl-de&ie=UTF8&qid=1357774599&sr=1-2
>
> I own the more recent edition and made a pass through it but I don't think it discusses safety that much. Any chapter I should be looking at?
>
> Andrei

No really. It is my favorite GC book, because it is the only one I know where so many GC algorithms get described, but I haven't read it in depth to be able to assert how safety is described.

And here is another one about real time GC that I own, although it focus on JVMs:

http://www.amazon.com/Realtime-Collection-Oriented-Programming-Languages/dp/3831138931/ref=sr_1_1?ie=UTF8&qid=1357806697&sr=8-1&keywords=Fridtjof+Siebert
January 10, 2013
On Thursday, 10 January 2013 at 00:50:30 UTC, Adam D. Ruppe wrote:
> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright wrote:
>> And that is not dereferencing null, it is dereferencing 0x1000000.
>
> Yes, but it is worth noting that dmd will happily compile that code, even if marked @safe - just because the pointer on the language level is null doesn't mean it is memory safe at the assembly level.
>
> the generated code with @safe is still just what we'd expect too:
>    3:   31 c0                   xor    eax,eax
>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR [eax+0x100000],0xa

That brings us to another point.

It does not matter how safe a language might be, if someone can change the assembly then everything is possible.

Or am I going too off-topic?
January 10, 2013
On Wednesday, 9 January 2013 at 22:29:36 UTC, Jonathan M Davis wrote:
> On Wednesday, January 09, 2013 14:14:15 Walter Bright wrote:
>> On 1/9/2013 1:23 PM, Mehrdad wrote:
>> > And are you considering reference counting to be garbage collection like
>> > Walter does,
>> 
>> It's not something I came up with. It is generally accepted that ref
>> counting is a form of garbage collection.
>
> I definitely would never have referred to reference counting as garbage
> collection and find it quite odd that it would be considered to be such, but
> Wikipedia does indeed list it as being a form of garbage collection:
>
> http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
>
> So, it's backing you up in your usage of the term.
>
> - Jonathan M Davis

This is what I was saying all along, in CS GC books reference counting is usually introduced as poor man's GC solution. As the most simple way to implement some kind of automatic memory management, specially in memory constrained devices at the expense of execution speed.

--
Paulo
January 10, 2013
On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote:
> On 1/7/2013 3:11 PM, H. S. Teoh wrote:

> One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety, which D aims to do. There's an inescapable reason why manual memory management in D is only possible in @system code.

I think that, at least for @system code (or invent another @), D programs should be able to require only GC-free code (forbiding, for example, features requiring GC).

I do some Linux kernel code. For most of it, I find it quite difficult to rely on the GC if I would use D instead of C.

One specific question: when handling an interrupt in Linux kernel, you are not allowed to sleep. But I think GC (and GC-triggering features) will sleep. So their use should be forbidden.

The main difference wrt to C programming for kernel: in C, to avoid sleeping, you need to stay away of some kernel/library functions; in D, you need to stay away of some language features.

Is one thing to avoid using specific functions. Is another thing to avoid using specific language constructs.
January 10, 2013
On Tuesday, 8 January 2013 at 23:10:01 UTC, Paulo Pinto wrote:
> Am 08.01.2013 17:12, schrieb Benjamin Thaut:
>> Am 08.01.2013 16:46, schrieb H. S. Teoh:
> Without dismissing your experience in game development, I think that your experience was spoiled by D's GC quality.
>
> After all, there are Java VMs driving missiles and ship battle systems, which have even higher timer requirements.

Yes, but they are relying on specific, very special constructs of Java, such as:

http://www.rtsj.org/specjavadoc/javax/realtime/NoHeapRealtimeThread.html
http://www.rtsj.org/specjavadoc/javax/realtime/RealtimeThread.html

which have very little, if any, to do do with regular Java. BTW, since when a Java programmer should be concerned about... heap? What's that? malloc()?

The fact that it uses the same syntax as Java, simply does not mae it Java, at least in the (regular) JVM sense.

January 10, 2013
On Thursday, 10 January 2013 at 09:05:53 UTC, eles wrote:
> On Tuesday, 8 January 2013 at 23:10:01 UTC, Paulo Pinto wrote:
>> Am 08.01.2013 17:12, schrieb Benjamin Thaut:
>>> Am 08.01.2013 16:46, schrieb H. S. Teoh:
>> Without dismissing your experience in game development, I think that your experience was spoiled by D's GC quality.
>>
>> After all, there are Java VMs driving missiles and ship battle systems, which have even higher timer requirements.
>
> Yes, but they are relying on specific, very special constructs of Java, such as:
>
> http://www.rtsj.org/specjavadoc/javax/realtime/NoHeapRealtimeThread.html
> http://www.rtsj.org/specjavadoc/javax/realtime/RealtimeThread.html
>
> which have very little, if any, to do do with regular Java. BTW, since when a Java programmer should be concerned about... heap? What's that? malloc()?

Any developer worth its salt should worry how their application makes use of the available resources.

>
> The fact that it uses the same syntax as Java, simply does not mae it Java, at least in the (regular) JVM sense.

The JVM is just a possible implementation of Java, the language.

It was quite an unfortunate decision for the Sun marketing team to call the language and the VM the same name.

This always ends up in lots of confusions when people consider the JVM to be the only way to execute Java.

Usually only developers with compiler design background end up making the difference, as languages and implementations are quite two different issues.


--
Paulo
January 11, 2013
On Thursday, 10 January 2013 at 08:38:18 UTC, Paulo Pinto wrote:
>
> This is what I was saying all along, in CS GC books reference counting is usually introduced as poor man's GC solution. As the most simple way to implement some kind of automatic memory management, specially in memory constrained devices at the expense of execution speed.
>
> --
> Paulo

This is likely a long shot (and may have already been proposed), but what the heck: If reference counting is considered to be garbage collection, and D is a garbage collected language, then can the current form of GC be replaced with a reference counted version that is fully automated, or does something like that always have to be manually hand crafted because it is not generic enough to fit in?

BTW: I did read through the responses concerning by past posts about the GG and memory safety, and I agree with those responses. I now have a much better understanding of what is meant by "memory safety", so thanks to everyone who took the time to respond to my ramblings, I've learned something new.

--rt
January 11, 2013
On 1/10/2013 4:05 PM, Rob T wrote:
> This is likely a long shot (and may have already been proposed), but what the
> heck: If reference counting is considered to be garbage collection, and D is a
> garbage collected language, then can the current form of GC be replaced with a
> reference counted version that is fully automated,

Yes, but you'd have to rework the semantics of array slices, function closures, etc., to add in the reference counts.