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