Peter Popov wrote:
As I was porting things from delphi to fp today I noticed the
following difference:
Delphi (2,5) : GetMem(p, 0) will set p to nil.
FPC (2.2.2, 2.3.1) : GetMem(p, 0) will assign something to p
Should it be forbidden do allocate a buffer of size 0 and reallocate it
Peter Popov wrote:
Well, if it points to something, then there is space, isn't it? Unless
it is clearly mentioned in the documentation that GetMem(p,0) results in
You get a pointer to some place where you may store 0 bytes, so nothing :-).
This can be useful because otherwise you may think
Peter Popov wrote:
Well, if it points to something, then there is space, isn't it? Unless
it is clearly mentioned in the documentation that GetMem(p,0) results in
You get a pointer to some place where you may store 0 bytes, so nothing :-).
This can be useful because otherwise you may think
Jonas Maebe wrote:
On 03 Sep 2008, at 22:23, Jonas Maebe wrote:
Yes, you did. Thanks. The bug is indeed in fillchar in generic.inc:
{ Align on native pointer size }
aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
dec(count,aligncount);
pend:=pdest+aligncount;
That
You get a pointer to some place where you may store 0 bytes, so nothing
:-).
This can be useful because otherwise you may think the allocation failed
if you get nil back. (And you've disabled heap exception).
you have a point
In FPC it is done by design. If 0 bytes are asked we allocate
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a
Martin Schreiber schrieb:
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The
