STANKULI%UWF.BITNET@cunyvm.cuny.edu ( stan kulikowski ii) (02/28/91)
(* i was having some strange behavior in one of my TP 5.5 programs... a string variable was behaving as if it still had the contents of previous assignments after it had been nulled. even the turbo debugger saw that the string had null value, but it still operated as if the ghost of its previous assignment was still there... *) program STRING_CHECK; var ANY_STRING : string; begin (* Main Program *) ANY_STRING := 'OK'; ANY_STRING := ''; writeln; writeln ('ANY_STRING is "',ANY_STRING,'"'); if (ANY_STRING 1! = 'O') and (ANY_STRING 2! = 'K') then writeln (' Uhoh.... string contents still there| ') else writeln (' Whew... string is gone. '); writeln (ANY_STRING 1!, ANY_STRING 2!); end. (* is this the way pascal is supposed to run? if so, this is very counterintuitive. when i null out a string, i obviously intend that all of its contents should be likewise null. surely any reference to a zero-length null string returns nil value. my understanding of fregean compositionality requires that if the value of any language structure is nil then any of its parts should also be nil else the value of the whole is not based on the values of its parts. am i missing something important here? this is elementary logic which was worked out in the 1920's. stan . stankuli@UWF.bitnet === close your eyes, my darling, or three of them at least --- -- old venusian lullaby *)
bobb@vice.ICO.TEK.COM (Bob Beauchaine) (02/28/91)
In article <26159@adm.brl.mil> STANKULI%UWF.BITNET@cunyvm.cuny.edu ( stan kulikowski ii) writes: >(* > i was having some strange behavior in one of my TP 5.5 programs... > a string variable was behaving as if it still had the contents of previous > assignments after it had been nulled. even the turbo debugger saw > that the string had null value, but it still operated as if the ghost > of its previous assignment was still there... >*) [example code deleted] Yes, your understanding of the way strings work in Turbo Pascal is incorrect. Nulling a string in Turbo Pascal only sets the length byte (byte 0) to the null character. Any information previously contained in the string is preserved. If you truly want to null the entire string, you would have to manually set each byte to #0 through an index or a call to fillchar(). (BTW, I verified the behavior of strings with your example code). >(* > is this the way pascal is supposed to run? > > if so, this is very counterintuitive. when i null out a string, > i obviously intend that all of its contents should be likewise null. > surely any reference to a zero-length null string returns nil value. > Depends on what's more important to you. Turbo seems to value speed above all else in programs, and simply nulling the length byte of a string is far superior than nulling each element from an efficiency standpoint. It also allows you to do things like turn off var string checking (compiler option $V) and manipulate strings whose maximum length may not be known at compile time. Nulling every element of a 50 character string when a 10 character length string was passed as a parameter would be disastrous. The moral of the story is : don't be stupid. If the length of your string is zero, any reference to any element of that string is at best undefined. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bob Beauchaine bobb@vice.ICO.TEK.COM C: The language that combines the power of assembly language with the flexibility of assembly language.
cctr132@csc.canterbury.ac.nz (Nick FitzGerald, CSC, Uni. of Canterbury, NZ) (02/28/91)
In article <26159@adm.brl.mil>, STANKULI%UWF.BITNET@cunyvm.cuny.edu ( stan kulikowski ii) writes: > (* > i was having some strange behavior in one of my TP 5.5 programs... > a string variable was behaving as if it still had the contents of previous > assignments after it had been nulled. even the turbo debugger saw > that the string had null value, but it still operated as if the ghost > of its previous assignment was still there... > *) > >[demo code deleted] > > (* > is this the way pascal is supposed to run? Dunno. Are strings part of standard Pascal?? - They seem to be implemented in so many different ways I always assumed the answer (to my question) was "No". > if so, this is very counterintuitive. when i null out a string, > i obviously intend that all of its contents should be likewise null. > surely any reference to a zero-length null string returns nil value. > > my understanding of fregean compositionality requires that >[stuff deleted] What's Fregean logic got to do with compiler implementation? 8-) > am i missing something important here? this is elementary logic which > was worked out in the 1920's. Is it relevant to programming, as opposed to "natural", languages? I though it was common knowledge that nulling a string in TP simply reset the index byte (AnyString(0)) to zero, and that to actually null out the contents you had to do that "manually". That is: AnyString:=''; is equivalent to AnyString(0):=char(0); not to for I:=length(AnyString) down to 0 do AnyString(I):=char(0); Nick.
John G. Spragge <SPRAGGEJ@QUCDN.QueensU.CA> (03/01/91)
The Turbo Pascal definition of a string would probably go thus (formally): a string consists ONLY of the characters from position 1 to <length>, where <length> is defined by byte 0. Thus, memory after the string (even if it is reserved for future string operations) is not part of the string; it is loose memory, the same way that memory left on the heap after a DISPOSE is loose memory, officially undefined. disclaimer: Queen's University supplies me with computer services, not my opinions. John G. Spragge
zhou@brazil.psych.purdue.edu (Albert Zhou) (03/03/91)
A string is like a pointer. After the length of a string becomes 0, its old content does not disappear. For example, x = 'I am here.'. after you assign x = 'I', its old content 'I am here' is still available. The only change is x[0] is 1 instead of 5 now.