× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.