>Similarly with a string var. But in the latter
>case... what, exactly, is happening in the variable? Is each individual byte
>in the string being set to a random 0-255 character? What about the length
>byte (assuming I didn't DIM it with a specified length)?

You've got it exactly. The compiler allocates space for the string, and 
whatever data happens to be sitting in memory underneath that space 
becomes the value of your string. It's effectively random.

The length byte will be given a random value whether you DIMmed it with a 
specific length or not. You may allocate space for a 172-byte string, but 
the length byte may happen to be 3; or, for that matter, the length byte 
may be 255, making a real mess.

It's a good idea to clear strings before using them. :-)

>Is this because, in the first case, the app just takes a quick look at the
>length byte, while in the second case it sets up two strings, given$ and "",
>and compares them? If their respective length bytes are different, does it
>stop right there, or does it do 255 successive comparisons?

I haven't disassembled FB's string-compare function, but in the C 
stringlib (and in the one I wrote for Object Basic) that's exactly how it 
works: the comparison halts at the first non-equal byte.

Even if the process does just boil down to a one-byte compare, there's a 
good bit of setup and cleanup associated with doing a string compare as 
opposed to a numeric compare.

In the long run I don't think it matters, unless the comparison is in the 
middle of some tight loop that runs tens of thousands of times. Speed 
isn't quite so important as it used to be. Use whichever way makes better 
sense visually, then worry about optimization after you've already 
determined that the code is too slow.

-Mars