Open mouth, extract foot, insert crow.
My apologies to Steve and the list.
Now, can someone recommend a good psychiatrist (or witch doctor) who can
explain why "memory leak" and "buffer overrun" are permanently switched in
my head?
Now, in an effort to dig an even deeper hole...
Not disagreeing with Simon but just to clarify. A memory leak is an
unintentional consumption of memory which, in the case of RPG and COBOL, is
only really possible when dynamically allocated memory becomes unreachable
(as in the example Simon gave).
So, I don't follow Steve's original assertion that Activation Groups hide
memory leaks - unless he means that reclaiming an AG will reclaim the
dynamically allocated memory - which, I would think, is a good point.
Regards
Paul Tuohy
ComCon
www.comconadvisor.com
www.systemideveloper.com
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Simon Coulter
Sent: 19 June 2008 00:28
To: RPG programming on the AS400 / iSeries
Subject: Re: Is RPG 'DEAD"
On 19/06/2008, at 3:23 AM, Paul Tuohy wrote:
I have no problem with explaining what you mean but you can't re-
define
existing terms to satisfy your requirements. There is absolutely no
connection between a memory leak and freeing storage.
Much as I think Steve is so wrong so often there is no point
discussing anything with him in this case he's not redefining terms:
A memory leak is storage that is not freed when it should have been.
A memory leak is where a program overwrites memory to which it
should not
have access. Worse case scenario being where it overwrites runnable
code in
memory (as happened or earlier versions of Windows but happens a
lot less
now)
No, that's a buffer overrun--also a direct consequence of C (and
derivative languages) having no concept of a fixed-length variables.
Freeing storage is returning storage that the program determines is no
longer required.
True, but neglecting to free such storage is a memory leak.
Absolutely no connection between the two except that they both
relate to
memory.
Might want to reconsider that statement in light of the above.
D buffer S *
C EVAL buffer = %ALLOC( 16776704 );
C SETON LR
is a memory leak. The leaked or lost memory will persist until the
job ends or the activation group is reclaimed. This is, of course,
significantly better than on other platforms where such storage is
not recovered even when the process terminates. An IPL is the only
option on such systems.
Lest anyone thing so-called "managed code" is immune to such problems
it's not--it's just less susceptible than C etc. Truly immune
languages probably don't exists but are more likely found amongst
those with compiler support for fixed-length variables such as RPG,
COBOL, and PL/1. Oh dear, all those archaic languages with inherent
advantages over the "modern" stuff.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
