× 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.



>So what now is the difference between
>the code that doesn't work and the
>code that was working?

Not the code.  The data declarations.  The D specs.  Not the code.

This is why Joe's technique of commenting out code works most of the time.
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.  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.  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.

If it isn't the code, then it must be the variable memory space.  Check the
data declarations, especially ones relating to parameters.  We can't see the
declarations for the /COPY'd in procedures...
  --buck


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.