Re: [fpc-pascal] ReAllocMem problem (?)
> Original Message
> Subject: Re: [fpc-pascal] ReAllocMem problem (?)
> From:"Marcel Martin" <[EMAIL PROTECTED]>
> Date:Wed, January 19, 2005 0:57
> To: "FPC-Pascal users discussions"
> --
>
> Marcel Martin a écrit :
> >
> > Hello,
> >
> > The following function SysReAllocMem comes from the file
> > /rtl/inc/heap.inc (FPC 1.9.7 / Win32)
> >
> > function SysReAllocMem(var p: pointer; size: ptrint):pointer;
> > [...]
> >{ Resize block }
> >if not SysTryResizeMem(p,size) then
> >begin
> > minsize := MemoryManager.MemSize(p);
> > if size < minsize then
> >minsize := size;
> > p2 := MemoryManager.AllocMem(size);
> > if p2<>nil then
> >Move(p^,p2^,minsize);
> > MemoryManager.FreeMem(p);
> > p := p2;
> >end;
> > [...]
> >
> > Maybe you have good reasons to write it like you did but is
> > the instruction "MemoryManager.FreeMem(p);" intentionally
> > always executed?
> > I thought that, in case it cannot increase the size of the
> > memory allocated to p^, the memory manager would set p to nil
> > but not that it would free it.
> >
> > Suppose OneClass has a field FP which points to an array of
> > pointers. In case of problem when attempting to increase the
> > size of FP^, FP is freed and OneClass can no more destroy the
> > pointed objects it created.
> >
> > Up to now, I believed the code was something like
> >
> > if p2<>nil then
> > begin
> > Move(p^,p2^,minsize);
> > MemoryManager.FreeMem(p);
> > end;
> > p := p2; <- p might be set to nil but it is not freed
> >
> > and, in OneClass, one could do
> >
> > Q := FP;
> > ReAllocMem(FP, NewSize (greater than current size));
> > if FP = nil then
> > begin
> > FP := Q;
> > Signal the 'Out of Memory' problem
> > end;
> >
> > Was your programming intentional? And if so, why?
> > Thanks.
>
> Considering the numerous answers I received, I am going to ask the
> questions otherwise: Is it a bug or not? Should I wait for a fixed version
> or should I manage to use it as it is because it will stay as it is? :-)
> Thanks.
The problem with your approach is: how do you know whether the memory was
extended, or left alone because there was no memory available to extend it ? In
general, shortage of memory produces a runtime error, but this is configurable
by a global var.
> There is an other thing I didn't notice yesterday when I sent my
> post. SysReAllocMem makes use of MemoryManager.AllocMem instead of
> MemoryManager.GetMem, i.e., SysReAllocMem fills up with 0s the
> new allocated memory (whereas the ReAllocMem doc says "only the
> used memory is initialized, extra memory will not be zeroed out").
Not zeroing it would trigger a bug in the compiler, so I left it in. (Can not
remember precisely, but the context was an array of pointers that is
realloc'ed, needing the new entries to be zero/nil).
Micha
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help needed with interfacing to C-object-files.
Jeff Pohlmeyer wrote:
My question : is the linker not smart enough to find out
by itself where to look for those missing object files ?
Not sure if I understand your question, but as Marc already
mentioned, you can control this with the -k-L compiler switch.
You can also control the way the compiler/linker searches
for various things using directives, eg:
{$OBJECTPATH path}
{$LIBRARYPATH path}
{$UNITPATH path}
- Jeff
OK, maybe you need more information. This is how I compile :
ppc386 -g -Sd -Fo/home/koenraad/owpd300 temp1
My program temp1 'uses' ownet.
In ownet.pp there are a number of routines that are in c-object files.
I include these object files with :
{$L owerr.o}
{$L ownetu.o}
etc.
If I compile this I get errors about not finding things used in
ownetu.o, e.g. (exact quote) :
/home/koenraad/owpd300/ownetu.o(.text+0xea): In function 'owNext':
: undefined reference to 'UMode'
etc.
If I look in ownetu.c I see :
#include "ownet.h"
#include "ds2480.h"
So I added in ownet.pp :
{$L ds2480.o}
then the errors about ownetu.o are gone. Likewise I have to add several
other object files not directly used in ownet.pp, but used in files that
are linked with {$L...}.
All those object files are in /home/koenraad/owpd300.
I assumed that when a routine uses some code in an object file which in
turn uses code in another object file, the linker would be smart enough
to know to look for that second object file. Of course, if those object
files are not in the search-path they will not be found.
Actually, when I add -va to the compile command, I see that the compiler
searches in a number of paths for code that is used. Why doesn't the
linker do the same ? My first tought would even be that I do not have to
add those first {$L...}'s.
Maybe these questions have nothing to do with fpc, but I'm trying to
understand, so I don't make these errors in the future. If this is
explained somewhere, do please give me some pointers.
Maybe I'm too used to using Delphi, where such things are hidden from
the developper.
Regards,
Koenraad.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help needed with interfacing to C-object-files.
On 12 Mar 2005, at 18:53, Koenraad Lelong wrote: I assumed that when a routine uses some code in an object file which in turn uses code in another object file, the linker would be smart enough to know to look for that second object file. No, the linker cannot know in which other object these routines are. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help needed with interfacing to C-object-files.
Am Sa, den 12.03.2005 schrieb Koenraad Lelong um 18:53:
> Jeff Pohlmeyer wrote:
> >>My question : is the linker not smart enough to find out
> >>by itself where to look for those missing object files ?
> >
> >
> > Not sure if I understand your question, but as Marc already
> > mentioned, you can control this with the -k-L compiler switch.
> >
> > You can also control the way the compiler/linker searches
> > for various things using directives, eg:
> >
> > {$OBJECTPATH path}
> > {$LIBRARYPATH path}
> > {$UNITPATH path}
> >
> >
> > - Jeff
> >
> >
> >
> OK, maybe you need more information. This is how I compile :
> ppc386 -g -Sd -Fo/home/koenraad/owpd300 temp1
> My program temp1 'uses' ownet.
> In ownet.pp there are a number of routines that are in c-object files.
> I include these object files with :
> {$L owerr.o}
> {$L ownetu.o}
> etc.
> If I compile this I get errors about not finding things used in
> ownetu.o, e.g. (exact quote) :
> /home/koenraad/owpd300/ownetu.o(.text+0xea): In function 'owNext':
> : undefined reference to 'UMode'
> etc.
> If I look in ownetu.c I see :
> #include "ownet.h"
> #include "ds2480.h"
> So I added in ownet.pp :
> {$L ds2480.o}
> then the errors about ownetu.o are gone. Likewise I have to add several
> other object files not directly used in ownet.pp, but used in files that
> are linked with {$L...}.
> All those object files are in /home/koenraad/owpd300.
> I assumed that when a routine uses some code in an object file which in
> turn uses code in another object file, the linker would be smart enough
> to know to look for that second object file. Of course, if those object
> files are not in the search-path they will not be found.
> Actually, when I add -va to the compile command, I see that the compiler
> searches in a number of paths for code that is used. Why doesn't the
> linker do the same ? My first tought would even be that I do not have to
> add those first {$L...}'s.
Since I have not enough knowledge about the linkers inner details and
about fpc's usage of it I can only advise you to have a look at the
original Makefile of the object files in question. The line and
variables envolved in linking the 1-wire files should give you some
hints on their dependencies.
If anything else fails you could translate the included headers
("ds2480.h" in this case) too and add them to the uses clause ...
> Maybe these questions have nothing to do with fpc, but I'm trying to
> understand, so I don't make these errors in the future. If this is
> explained somewhere, do please give me some pointers.
I think you should read the man page of the linker.
> Maybe I'm too used to using Delphi, where such things are hidden from
> the developper.
That's the nice part of Delphi. :)
HTH,
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReAllocMem problem (?)
Micha Nelissen wrote: The problem with your approach is: how do you know whether the memory was extended, or left alone because there was no memory available to extend it ? In general, shortage of memory produces a runtime error, but this is configurable by a global var. No, that's easy. If the returned pointer is nil, it signals the problem. But returning a nil pointer doesn't mean losing the pointed memory area. We can save the pointer value before calling ReAllocMem (in such situation, Delphi 5 returns a nil pointer but the memory area is not lost). The problem comes overall from the fact that ReAllocMem was badly designed (presumably by Microsoft, but I don't know). But, now, it is as it is and we live with that. ReAllocMem shouldn't destroy anything just because it cannot increase something. For instance, in my program Primo (Primality certification, written with Delphi 5), if such a problem occurs (OutOfMemory), Primo will terminate but BEFORE, it will try to save data in order to not lose all the work already done [*]. Now, if the memory manager kills the addresses of the created objects, no more things can be saved. [*] Well, Primo automatically saves the work in progress every 10 minutes but anyway. I would be dead since long otherwise, some Primo users reported certification running times greater than 4000 hours :-) There is an other thing I didn't notice yesterday when I sent my post. SysReAllocMem makes use of MemoryManager.AllocMem instead of MemoryManager.GetMem, i.e., SysReAllocMem fills up with 0s the new allocated memory (whereas the ReAllocMem doc says "only the used memory is initialized, extra memory will not be zeroed out"). Not zeroing it would trigger a bug in the compiler, so I left it in. (Can not remember precisely, but the context was an array of pointers that is realloc'ed, needing the new entries to be zero/nil). It would have been preferable to try to fix this particular bug otherwise. The fact that the blocks of memory are set to 0 is a big waste of time. In the big integer library [*] I am adapting to Free Pascal (and not only big integers, but also big polynomials over GF(2), big real/complex floats), the routines make lots of memory 'reallocations'. [*] BTW, congratulations for the 1.9.8 version. At the moment the running times I get are slightly better than those got with Delphi. Not much better but better anyway ;-) Well, if you cannot change this, you cannot. Currently, I only use ReAllocMem when the memory size decreases, otherwise I put a BUGGY_REALLOCMEM directive in the code that enables the use of GetMem and Move instead of ReAllocMem. Using GetMem and Move is not really slower than the current behaviour of ReAllocMem when the memory size increases. And, this way, I am sure (well, almost) that the content of the memory area I want to increase won't be destroyed. mm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReAllocMem problem (?)
On Sat, 12 Mar 2005 21:46:15 +0100 mm <[EMAIL PROTECTED]> wrote: > Micha Nelissen wrote: > > >The problem with your approach is: how do you know whether the memory > >was extended, or left alone because there was no memory available to > >extend it ? In general, shortage of memory produces a runtime error, > >but this is configurable by a global var. > > > No, that's easy. If the returned pointer is nil, it signals > the problem. But returning a nil pointer doesn't mean losing > the pointed memory area. We can save the pointer value before > calling ReAllocMem (in such situation, Delphi 5 returns a nil > pointer but the memory area is not lost). Ah I see, you are right. The documentation does not explicitly say that returning a nil pointer means the memory area has been freed. So both choices are possible within documentation. In this case I would advise not to free the pointer and explicitly document this choice in the freepascal documentation. (As the user can free the area himself anyways, but can not bring it back). What do the other fpc developers think? > >Not zeroing it would trigger a bug in the compiler, so I left it in. > >(Can not remember precisely, but the context was an array of pointers > >that is realloc'ed, needing the new entries to be zero/nil). > > > It would have been preferable to try to fix this particular bug > otherwise. The fact that the blocks of memory are set to 0 is > a big waste of time. In the big integer library [*] I am adapting > to Free Pascal (and not only big integers, but also big > polynomials over GF(2), big real/complex floats), the routines make > lots of memory 'reallocations'. Maybe it would help you more to allocate more space in advance? Or use a data structure not requiring reallocations ? Just some suggestions... I think it's the same as with classes that are automatically zeroed when creating, but those aren't so big usually... Probably the bugs in the compiler can be found and fixed easily, but also this choice I leave to the core developers. Also seen the fact that delphi does not zero it also, can argue for us not doing it either... Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReAllocMem problem (?)
Micha Nelissen wrote: In this case I would advise not to free the pointer and explicitly document this choice in the freepascal documentation. (As the user can free the area himself anyways, but can not bring it back). Yes, exactly. Maybe it would help you more to allocate more space in advance? Or use a data structure not requiring reallocations ? Just some suggestions... Your are right, it would be faster but this is not possible. For instance, suppose you are a user of the library and you want to compute !1, i.e., Factorial 1. Currently, all you have to do is to write "IFactorial(N,1)". Now what if, before calling IFactorial, it is necessary to estimate the size of !1 in order to oversize N? Yes, you lovely archive the library in the trush and you search for an other one :-) mm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] RE: Help needed with interfacing to C-object-files.
I still don't understand what sort of c "package" you have that generates a bunch of object files, but doesn't create a shared library or static archive. Does it have its own makefile or configure script? Sometimes adding --enable-shared or --enable-static to configure will tell it to build a library. > > Maybe I'm too used to using Delphi, where such things > > are hidden from the developper. > That's the nice part of Delphi. You are talking about searching the system for object files generated by another compiler and automatically linking them into an executable ? I didn't know Delphi could do that ;-) - Jeff -- __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReAllocMem problem (?)
mm wrote: compute !1, i.e., Factorial 1. Currently, all you have Of course, I should have written "1!" and not "!1". mm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RE: Help needed with interfacing to C-object-files.
Am So, den 13.03.2005 schrieb Jeff Pohlmeyer um 00:03: [..] > > > Maybe I'm too used to using Delphi, where such things > > > are hidden from the developper. > > > That's the nice part of Delphi. > > You are talking about searching the system for object > files generated by another compiler and automatically > linking them into an executable ? No, it doesn't (you know that). But it does free you from thinking about makefiles or the like in building. Very comfortable but not sufficient in any case... > I didn't know Delphi could do that ;-) In theory any programming language can do anything ... give it some arms, legs and the way to the refrigerator and it'll fetch you another beer. ;) Cheers, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
