 | rickman wrote:
> Anton Ertl wrote:
===snipped
> The result is true only because you want to define it as true. Other
> than by comparing it to other math operations, you have not shown any
> basis for the result being one thing or another.
Then what should it return?
Section 3.1.3.4 of the standard allows explicitly for counted strings
of length zero; and as COUNT gives the character string, and there are
no restrictions on length (given that it's unsigned, so "negative"
strings are out, by definition). According to the standard, the null
string exists.
Then we have some simple issues to decide.
Is moving a null string ambiguous (or undefined)? The standard is
silent on null strings; it implies that _nothing_ is done when the
length of a string is zero. However, since not doing the move is
indistinguishable from moving the null string, it can't be an ambigous
condition, since we can't tell the difference between doing it and not
doing it.
Is reading a null string undefined? No; the result of READ-LINE is
explicitly allowed to be zero. Ditto WRITE-LINE.
As for COMPARE (a test of equality will suffice to make the point,
rather than less than, equal, greater than): A null string is equal to
itself (true of any string). A null string is equal to another null
string (because they are indistinguishable; the address is not part of
the comparison). A null string is not equal to any non-null string
(because the lengths differ).
Is searching for a null string undefined?
>
> How about if you consider the search in its own right? I say this
gives
> you no insight and so searching for a null string should be an
invalid
> operation, just like searching for a string with a negative length.
First, by definition a negative string length isn't possible; the
standard explicitly requires an unsigned value (all the strings are
c-addr u ). Secondly, the standard doesn't really do "invalid
operation"; it tends towards ambiguity or undefined (i.e., you define
the result for your system, the standard doesn't).
There are three null string scenarios to account for.
1. HERE 0 S" FRED" SEARCH ; that is, searching a null string.
2. S" FRED" HERE 0 SEARCH; "Can you find a null in FRED?"
3. HERE 0 HERE 0 SEARCH ; that is, can I find a null string in a null
string?
Case (1). "Did you find FRED in the null string?" is no. It is
certainly not yes; no string, except another null string, can be found,
because _the second argument is longer_.
Case (2). If this case is undefined, then (1) would have to be
undefined too. If the strings are of different lengths as in (1) and
(2), then finding string A in string B guarantees that you CAN'T find
string B in string A.
Case (3). This is to compare two identical strings (as in, for example
S" FRED" S" FRED" SEARCH ); they are equal, and hence I can find a null
in a null. Doesn't look ambiguous to me, and certainly the functional
equivalent COMPARE isn't; but if you insist, then (1) and (3) must be
undefined too.
This would cause real problems as
STRA STRB SEARCH and STRA STRB COMPARE
would give different results _only for the null string_. So a null
operand COMPARE would have to be undefined too... and on we go, making
just about everything that can take a null string undefined...
>
> If you need it to return some particular result, you can always give
it
> a wrapper that detects a zero length and returns zero.
>
> If this has no practical need (no one has asked for it because it
> impacted their ability to solve a problem) then why bother with it?
It is needed. If your search didn't have a well formed result for a
null operand, how could you search for a string in a file? It might
have one or more zero length lines. That's a pretty common requirement.
--
Regards
Alex McDonald
|
|
