[fpc-devel] Access Violation with nested DLL's compiled byFPC(andsome more info on bug #4538)

[L505]

> This does not make sense to me. When you return a string (from a
> function in a DLL or anywhere else), this string will have a
> reference count of at least 1 and thus will not be cleaned up by anyone.
>
> The only problem I can see that can occur is in case the program and
> the DLL indeed use different memory managers, in which case you can
> have a situation where memory allocated by the dll's memory manager
> is freed "to" the program's memory manager, and that will probably
> confuse the hell out of it (even if they are essentially the same
> memory manager, just using different data structures).
>
>


I apologize, I should have said that you'd not have exactly the same problems with
returning a string - they are different problems but the basic point and idea remains
the same: no matter what you do, strings will cause problems. What I should have said
was there would still be all sorts of problems with returning a string - not
necessarily the reference count problem, but other issues that cause similar havoc,
such as two memory managers not communicating with each other. There are so many
problems to consider, that a programmer once again spends more time thinking about
the possible problems instead of programming a solution that works reliably.

When it comes time to maintain your application in the future, or modify your DLL,
and if you did some how manage to get strings working by using setlength's in the
right place, and not returning a string as a result, you may not remember why these
workarounds were in place and what workarounds must be left in the code if you change
the code.  If you go in and modify a DLL one day in the future, with a string that is
just barely working as is with workarounds, the application might go BOOM when you
make one little change to the DLL. In other words, even if you can get a string
working as a parameter being sent, received, and allocated properly (but not as a
function result), it may be a dangerous bomb waiting to tick off in the future when
you try and maintain or upgrade your DLL. You must spend minutes/hours going through
every possible problem that could happen with the modifications you make, every time
you upgrade your DLL.

If I change this code in my DLL, does that mess up the work around's that kept the
bomb from going off? If I change this other code in my DLL, is the string still safe?
There are just too many issues to think about. Unless, of course, there is a sharemem
unit for FPC. And with a sharemem unit, since I've never used one in Delphi or FPC,
I'm not sure how reliable they are. i.e are there bugs in the sharemem units that
cause problems in Delphi, anyone know?