Yep - I've run into that at some time as well.
I seem to remember this being a problem with the editor or with
reading/writing values to an mv file rather than internal string
If you re-edit the source, do you find that it has been split into :

002 ":CHAR(255):"CAT"


-----Original Message-----
[] On Behalf Of Wjhonson
Sent: Friday, July 13, 2012 1:49 PM
Subject: Re: [U2] trimming a list (a test of your ability)

Well I'll be a horned toad.
However try this

001 PRINT "DOG":CHAR(255):"CAT"
Up arrow mode
001 PRINT "DOG ":CHAR(255):"CAT"


No closing quote

The compiler doesn't see the FF as the same "sort" of thing as other
characters even if the editor does

-----Original Message-----
From: u2ug <>
To: U2 Users List <>
Sent: Fri, Jul 13, 2012 10:43 am
Subject: Re: [U2] trimming a list (a test of your ability)

Just to be complete :
for j=0 to 255
   if char(j)='x' then continue
   if j=0 or l#7 or p#5 then
       crt "j=":j
       crt " x  =[":x:"]"
       crt " len=":l
       crt " pos=":p

x  =[abcxyz]

-----Original Message-----
n Behalf Of u2ug
ent: Friday, July 13, 2012 1:10 PM
o: U2 Users List
ubject: Re: [U2] trimming a list (a test of your ability) For universe,
I believe that used to be true - I seem to recall running into his maybe
15+(?) years ago.
 also seem to recall that the resolution to this issue was, as was
mentioned, repending all strings with a length.
Try it:
 crt "[":x:"]"
 crt len(x)
 crt index(x,"x",1)
[abc xyz]

----Original Message-----
n Behalf Of Wjhonson
ent: Friday, July 13, 2012 12:27 PM
ubject: Re: [U2] trimming a list (a test of your ability)

A string is stored in a fixed length *spot*, and is ended by an FF.
his is *why* if you actually try to create a string in BASIC (or read
one) with n embedded FF in it, the runtime will "truncate" the string It
doesn' actually runcate the variable spot, what it does is fool the
run-time into thinking ou've hit the "end" of the string so it ignores
anything else after it thinking t's leftover garbage from trimming or
So initially let's say you get a "spot" of 8 bytes which is the default
size of ny variable, if you're string is only 8, it will then allocate
you 50 bytes, nd *move* the string into that new spot and the old spot
will just be a direct ointer to the new spot.
If you exceed 50 bytes, it then *allocates* you a new *spot* of 250
bytes lsewhere, and the original 8 byte spot now points at the new spot
And so on.  
However, as it scans the string looking for the *end*, if it encounters
an FF, hat's the end.
he run-time will also garbage-collect the old spots by the way, for use
as ther things.
I'd be surprised if it actually wastes effort to store the length
constantly at he fore, but I'm willing to be edumacated on that abstruse
point. (Or pointer) Will

-----Original Message-----
rom: Wols Lists <>
o: u2-users <>
ent: Fri, Jul 13, 2012 3:53 am
ubject: Re: [U2] trimming a list (a test of your ability)

n 12/07/12 16:15, Dave Laansma wrote:
I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares'
about pointers, it still has to get to the end of the 'string' one way
or nother.
xcept that a string, as far as I am aware, uses the "pascal method" I
hink it's alled - namely a string is stored as its length followed by he
string (or a ollerith string as I used to do in FORTRAN).

So, the question then is, does concatenation := establish and append to
a string' faster than <-1>?
ery much so

And if so, why doesn't the database use the same logic for <-1> as it
does for = since technically they're accomplishing the same thing?

cause it's doing it in a completely different way. The <-1> logic just
happens o work" whereas the append logic was designed to work hat way.
f you use a field number, the code searches for that field - I think it
akes he field as a counter, and searches the string decrementing the
ounter every ime it hits a field mark. When the counter hits zero it's
ound what it's ooking for.
f course, if you start at -1, it never hits zero and ends up at the end
f the tring. But this is by accident not design. To do what you uggest
would require pecial case code which doesn't - logically - elong there.
David Laansma
IT Manager
Hubbard Supply Co.
Direct: 810-342-7143
Office: 810-234-8681
Fax: 810-234-6142
"Delivering Products, Services and Innovative Solutions"

-Users mailing list
2-Users mailing list

2-Users mailing list

2-Users mailing list

U2-Users mailing list

U2-Users mailing list

Reply via email to