Hi,
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Op Wed, 8 Mar 2006, schreef Micha Nelissen:
Hi,
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
No, it is the responsibility of the programmer.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, 8 Mar 2006 18:10:38 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 8 Mar 2006, schreef Micha Nelissen:
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
No, it is the responsibility of the programmer.
Nope. At least the compiler depends on it being
On 8 mrt 2006, at 18:19, Micha Nelissen wrote:
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
No, it is the responsibility of the programmer.
Nope. At least the compiler depends on it being zeroed.
Where? It's a bug if it does.
The FPC heap
manager zeroes it, as well.
On Wed, 8 Mar 2006 18:19:40 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
On Wed, 8 Mar 2006 18:10:38 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 8 Mar 2006, schreef Micha Nelissen:
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
No, it is the
Op Wed, 8 Mar 2006, schreef Micha Nelissen:
On Wed, 8 Mar 2006 18:10:38 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 8 Mar 2006, schreef Micha Nelissen:
Shouldn't ReallocMem in CMem zero the newly allocated bytes ?
No, it is the responsibility of the
Hello, I've recompiled a Kylix app
into freepascal that uses threads and now with FPC I've noticed that
the memory used by my program is growing until it gets all of the
system memory.
So I've made a simple app to test what was wrong, and this app shows
that the problem is with thread
On Wed, 8 Mar 2006 18:33:53 +0100
Mattias Gaertner [EMAIL PROTECTED] wrote:
Nope. At least the compiler depends on it being zeroed. The FPC heap
manager zeroes it, as well.
Not under linux. Are you sure?
Hmm, that was changed then and the compiler was fixed; probably due to me
mentioning
On Wed, 8 Mar 2006 19:10:55 +0100
Mattias Gaertner [EMAIL PROTECTED] wrote:
On Wed, 8 Mar 2006 19:01:11 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
Hmm, that was changed then and the compiler was fixed; probably due to me
mentioning it on IRC sometime ago, also :-). The name has 'alloc'
On Wed, 8 Mar 2006, Micha Nelissen wrote:
On Wed, 8 Mar 2006 19:10:55 +0100
Mattias Gaertner [EMAIL PROTECTED] wrote:
On Wed, 8 Mar 2006 19:01:11 +0100
Micha Nelissen [EMAIL PROTECTED] wrote:
Hmm, that was changed then and the compiler was fixed; probably due to me
mentioning
On Wed, 8 Mar 2006, Dale Welch wrote:
does anyone know of a full implementation of a memory based dataset?
tmemdataset and sdfdataset both do not implement the
canmodify property.
But they are both read-write. I'll see about fixing the CanModify
property, though.
i would like a memory
On 8 mrt 2006, at 20:34, Michael Van Canneyt wrote:
What has 'alloc' to do with cleaning/zeroing?
It is *the* difference between GetMem and AllocMem.
Not in FPC. Reallocmem just resizes. No zeroing is done, as already
explained
by Jonas and Daniel.
Yes, but allocmem() does zero the
On Wed, 8 Mar 2006, Jonas Maebe wrote:
On 8 mrt 2006, at 20:34, Michael Van Canneyt wrote:
What has 'alloc' to do with cleaning/zeroing?
It is *the* difference between GetMem and AllocMem.
Not in FPC. Reallocmem just resizes. No zeroing is done, as already
explained
by Jonas
Complementing my last post about threads, this is the log file generated
by valgrind running this program.
==3968== Memcheck, a memory error detector.
==3968== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==3968== Using LibVEX rev 1367, a library for dynamic binary
(Second send, it seems that mails from my old email address do not reach
fpc lists)
Den Jean wrote:
Hi,
I have a strange problem. My Qt4 demo program worked
fine with FPC 2.0.0, but crashes (div by zero) with FPC 2.0.2.
Debugging shows that indeed a div by zero is done within
the Qt4 lib.
15 matches
Mail list logo