On Thursday, 13 November 2014 at 10:17:35 UTC, ketmar via
Digitalmars-d-learn wrote:
On Thu, 13 Nov 2014 10:08:47 +0000
Chris via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:
Interesting though that it never crashes on Linux, only on
Windows did this cause problems.
seems that libc allocator is not marking free pages as
"unreadable",
and windows libc allocator does something like this. i got alot
of such
"use after free" things in my C code, but valgrind is brilliant
to
track that down. i miss valgrind on windows. ;-)
now i prefer to write code in GNU/Linux if possible and use
valgrind to
track down memory issues, and only after it works on linux and
valgrind
is happy, i'm starting to port it to windows. this, of course,
hard to
do with winapi-tied code, but wine/winelib can help there too
(to some
extent).
To whom it may concern: For Windows I had to write safe code. My
"skating on razor blades" code[1] didn't work there (dodgy
casts). I have to make an immutable copy of the short[] array I
get from C (an extra step I wanted to avoid). In a way it's much
cleaner. I copy the array and free the memory in C immediately
afterwards. It's not the Windows crashes with the unsafe code,
it's just that freeing the memory and reading the array are out
of sync (across threads), giving rise to undefined behavior (it
reads random values from memory).
Having said this (repentantly), it took me a while to check the C
code and the memory allocations/deallocations that go on there,
to make sure everything is fine in C (and D). I have to say that
it's much nicer to work with GC than with manual memory
management, because it is a tedious task that keeps you from
writing useful code.
[1]
http://forum.dlang.org/thread/yhticlpnygtjkdcfj...@forum.dlang.org
