Modifying existing data allocations

[Jeff Markel <JMarkel@xxxxxxxxxx>]

Hi Buck! You wrote:

Message: 1
From: Buck Calabro <Buck.Calabro@commsoft.net>
To: rpg400-l@midrange.com
Subject: RE: URGENT! - Program Error
Date: Mon, 16 Sep 2002 11:02:33 -0400
Reply-To: rpg400-l@midrange.com

                                ...Because the corruption may occur in the
new code by modifying existing data
                                declarations beyond a boundary that was
never touched before.  But simply
                                adding or removing a variable might cause
existing, unchanged code to
                                corrupt an area of memory that was
previously unimportant.

                                Think of it like this:

                                var1 10
                                (internal storage for Level indicators)
                                var2 10
                                (internal storage for I/O control blocks)
                                code block 1
                                code block 2

                                Code block 1 has a bug which modifies var1
beyond it's allocated 10 bytes -
                                into the L1 area [How would this happen?
/jam].  But the code doesn't use L1, so the bug is not noticeable
                                to your code.  Now, delete var2.  The
existing code block, with the existing
                                bug (that you didn't notice before) might
change memory through the Lx area
                                down into the I/O area. [I'm not sure I
understand this. /jam] Boom.

                                Remember that the internal areas are not
controllable by you, and that the
                                compiler may well move that I/O internal
area right up under var1 instead of
                                under var2.  This is fictitious and
speculative, but the point I am trying
                                to hammer at is that your code may well
already have a bug that you don't
                                notice because the 'working' code is
corrupting memory that you aren't
                                referencing.  But change the storage map in
any way, and the bug may now be
                                corrupting memory that you DO reference.
[Please explain how! /jam]

Can you give a more specific example of this type of bug, Buck? I'd like to
make sure I understand it, so I won't make the same mistake!

Thx!
Jeff