For universe, I believe that used to be true - I seem to recall running into 
this maybe 15+(?) years ago.
I also seem to recall that the resolution to this issue was, as was mentioned, 
prepending all strings with a length.

Try it:

  crt "[":x:"]"
  crt len(x)
  crt index(x,"x",1)

[abc xyz]

-----Original Message-----
[] On Behalf Of Wjhonson
Sent: Friday, July 13, 2012 12:27 PM
Subject: 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.
This is *why* if you actually try to create a string in BASIC (or read one) 
with an embedded FF in it, the runtime will "truncate" the string It doesn' 
actually truncate the variable spot, what it does is fool the run-time into 
thinking you've hit the "end" of the string so it ignores anything else after 
it thinking it's leftover garbage from trimming or something.

So initially let's say you get a "spot" of 8 bytes which is the default size of 
any variable, if you're string is only 8, it will then allocate you 50 bytes, 
and *move* the string into that new spot and the old spot will just be a direct 
pointer to the new spot.

If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes 
elsewhere, 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, 
that's the end.
The run-time will also garbage-collect the old spots by the way, for use as 
other things.

I'd be surprised if it actually wastes effort to store the length constantly at 
the fore, but I'm willing to be edumacated on that abstruse point. (Or pointer)


-----Original Message-----
From: Wols Lists <>
To: u2-users <>
Sent: Fri, Jul 13, 2012 3:53 am
Subject: Re: [U2] trimming a list (a test of your ability)

On 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 
Except that a string, as far as I am aware, uses the "pascal method" I hink 
it's called - namely a string is stored as its length followed by he string (or 
a Hollerith string as I used to do in FORTRAN).
 So, the question then is, does concatenation := establish and append to  a 
'string' faster than <-1>?
Very 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?
ecause it's doing it in a completely different way. The <-1> logic just happens 
to work" whereas the append logic was designed to work hat way.
If you use a field number, the code searches for that field - I think it akes 
the field as a counter, and searches the string decrementing the ounter every 
time it hits a field mark. When the counter hits zero it's ound what it's 
looking for.
Of course, if you start at -1, it never hits zero and ends up at the end f the 
string. But this is by accident not design. To do what you uggest would require 
special case code which doesn't - logically - elong there.
> Sincerely,
 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"
2-Users mailing list

U2-Users mailing list

U2-Users mailing list

Reply via email to