NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/pascal/7843

Text File | 1993-01-04 | 4.0 KB | 86 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!usc!howland.reston.ans.net!paladin.american.edu!gatech!taco!csemail.cropsci.ncsu.edu!samodena
From: [e-mail] (S. A. Modena)
Subject: Re: TVision : BUG in my head or in TV?
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Crop Science Dept., NCSU, Raleigh, NC 27695-7620
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 4 Jan 1993 20:32:55 GMT
Lines: 74

In article <[e-mail]> [e-mail] (Steph) writes:
>In article <[e-mail]> [e-mail] (Duncan Murdoch) writes:
>>In article <[e-mail]> [e-mail] (Steph) writes:
>>>What happens is this : I found out (after many bugs with this), that
>>>EndOfStatic (my before-adding-spaces-to-AText-length) is set to 0
>>>after the call to TStaticText.Init!  Why is this so?
>>
>>This is a nasty surprise designed into TurboVision.  TObject.Init zeroes out
>>all fields of any descendant.  It's not done that way in OWL, and shouldn't
>>be in TurboVision, but Borland won't change it now because they're afraid of
>>breaking existing code.
>>
>>Duncan Murdoch
>>[e-mail]
>>.
>>.
>
>Well, at least I'm not crazy!  Hmmm, how can TObject.Init zero out
>fields of descendant fields?  How can it know what its descendant
>fields will be?  Oh well.  Thanks a lot, I guess I'll have to build
>around it then!
>
>Steph.

Well, the answer resides in looking at the OBJECTS.PAS unit code.

I'm paraphrasing now:

INIT TObject portion of the new object.  Then get the quantity of
bytes for the "rest" of the new object SizeOf(TNewObject)-SizeOf(TObject),
Use FillChar() to put #$00 for the correct distance right *after* the
end of TObject in memory.

This harkens back to a rather ANCIENT debate as to whether a program
or operating system should PRE-initialize the memory image to ZEROs
or leave whatever garbage values were in memory at the instance of
"loading."   Bugs due to UNinitialized memory variables SET TO ZERO or
NIL (for pointers) are easier to diagnose and are more CONSISTANT in
behavior than are  UNinitialized memory variable with RANDOM garbage
values that "work" sometimes and don't "work" other times.

NOTE: MASM and TASM have directives for allocating either memory INITIALIZED
to $00 or to be left in garbage state.

Therefore, Borland made a design decision.  Contrary to Duncans assertion,
it is not a "mistake."  It is a design decision.  Though I do not know
the intimate details of Protected Mode programming and Windows programming,
I do know that there is a significant difference from DOS programming
and MEMORY MANAGEMENT.  Therefore, without first hearing a pro- or con-
debate on the merits of memory zeroing--or not--in a particular situation,
I'd hesitate to criticize TObject memory zeroing.

As far as Steph needing to learn to "build" around it (memory zeroing in
DOS TV), I'd put forth that I use it to *advantage* and am quite glad
it is done.  :^)

Of course, anyone who bought BP7 also got TV source code and therefore
can easily comment out the couple of lines that do the memory
zeroing...and find out whether your code generation life is happier and
easier!  :^)

Steve
---
+------------------------------------------------------------------+
|     In person:  Steve Modena     AB4EL                           |
|     On phone:   [phone]                                   |
|     At e-mail:  [e-mail]                           |
|                 [e-mail]                |
|                 [ either email address is read each day ]        |
|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
+------------------------------------------------------------------+
         Lighten UP!  It's just a computer doing that to you.    (c)
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO