Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ukma!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!cfchiesa From: cfchiesa@bsu-cs.UUCP (Christopher Chiesa) Newsgroups: comp.os.vms Subject: Re: pascal strings Message-ID: <2895@bsu-cs.UUCP> Date: 6 May 88 17:33:11 GMT References: <8805021136.AA05274@decwrl.dec.com> <2834@bsu-cs.UUCP> <2864@bsu-cs.UUCP> Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 31 Summary: Flatten my head and call me a brick In article <2864@bsu-cs.UUCP>, I wrote: > In article <5302@megaron.arizona.edu>, robert@arizona.edu (Robert J. Drabek) writes: > > In article <2834@bsu-cs.UUCP>, cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes: > > > : I just wanted to point out that in this context, the Vax Pascal LENGTH > > : function does NOT return the contents of the varying_string ".length" field. > > : It returns the DECLARED SIZE of the particular variable, in this case the > > : value 255, regardless of the number of "valid characters" actually in the > > : string. > > > > > > Why don't I see this? I've used this fairly often and it seems I always > > came up with the number of valid characters. > > That's a VERY GOOD question! Perhaps we have different versions or releases Well. I stand chagrined. Several other people and myself have tried the LENGTH function within the last few days, and it does indeed seem to give the desired results. Thinking back, I guess the problem *I* had with it, was that it DOES NOT IGNORE TRAILING BLANKS when one reads blank-filled records from a file, and my memory of writing MY OWN "LENGTH" FUNCTION, had to do with counting only the "valid" characters in the string, disregarding trailing blanks. My apologies for cluttering up the net with a mistaken statement/posting. Glad you people are on the ball! :-) Chris Chiesa -- UUCP:!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP