String>>indexOfAnyOf:startingAt:

Long time, no talk.
The first time I need to touch an application in a year,
I promptly come upon strange behaviour in Dolphin, exposed
by some other bug ...


I need to determine, whether some strings contain
$< or $>, and after some browsing decide to use
indexOfAnyOf:startingAt:.

3000 strings are searched, 83 found are collected
and the first result ... does not contain either
$< or $>.

The string in question is a result of some file contents
slurped in as a whole and then split repeatedly with
subStrings: IIRC. Anyways, it had 6 \0-bytes at the end.

Now indexOfAnyOf:startingAt: is a thin wrapper around
the CRTLibary function strcspn, which returns the number
of characters *not* enumerated, counted from the beginning
upto and including the \0 at the end.

Which \0 then, you ask? The first of the six, of course.

Sooo.... since this character index (141) is below the
string size (146), the wrapper responds as if one of the
special characters were found and the string is erroneously
reported.

Now, where's the bug?
- my other code: creating unexpected file content?
- my Dolphin code: splitting file contents into strings?
- Dolphin: creating strings with \0's at the end?
- Dolphin: passing such strings on to CRT functions?
- Microsoft: out of habit?
- K&R: for promoting zero-terminating strings?

Mostly I blame Borland for making the access to Paradox tables
so heavily dependent on so easily corruptible indices. That's
where the unexpected file contents come from ...

s.

Stefan Schmiedl wrote:

> Sooo.... since this character index (141) is below the
> string size (146), the wrapper responds as if one of the
> special characters were found and the string is erroneously
> reported.

Which version of Dolphin are you using ?  In my image (D 5.0.4) the code
explicitly sets for this case and falls back to the superclass implementation,
and it seems to work OK.

(Incidentally, for OA, the super-send starts again at the begining of the
sting, wouldn't it be better to continue at 'span + start' rather than 'start',
to avoid retesting the characters that the C library has already looked at ?)

    -- chris

On Wed, 3 Nov 2004 07:58:03 -0000,
Chris Uppal <[hidden email]> wrote:
The system seems to be 5.1, which gets me wondering since I thought
that I had everything here patched...

The code looks roughly like

|span|
span := CRTLibrary default strcspan ...
^span + start > self size
  ifTrue: [0]
  ifFalse: [span+start]

no supersend here.

Anyways, rebuilding the Paradox index removed the problem, as I
expected.

s.

Stefan,:

> The system seems to be 5.1, which gets me wondering since I thought
> that I had everything here patched...

The method was updated in 5.1.2 to fix this problem.  See issue #715 on the
following page....

http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL2.htm

The current version of Dolphin is 5.1.4

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

On Wed, 3 Nov 2004 16:02:48 -0000,
Ian Bartholomew <[hidden email]> wrote:
And I seem to have upgraded to this on all working images, but this one,
which has been dormant since fall last year. That's what I deserve for
letting things rest :-)

s.

Stefan Schmiedl wrote:


Yes, if you consider the contents unexpected,
then by all means keep it confined inside the
original zoo.  Convert it to expected form
before letting it loose on the locals.

On the other hand, if the contents are
what you expect them to be, then there is
definitely a problem - somewhere else.


> - my Dolphin code: splitting file contents into strings?


Hard to tell - since you didn't post the snippet in question.
But it seems an unlikely location for the described problem.


> - Dolphin: creating strings with \0's at the end?


 From your description, I'd expect they're already
in the input that Dolphin is getting.


> - Dolphin: passing such strings on to CRT functions?


Nothing wrong with leveraging.

However, one might well argue that since Dolphin does not
itself zero terminate strings, but *does* hand off to
a function which considers \0 to be a string terminator,
that Dolphin, in recognizing the potential clash,
should be sanity testing the final result before answering.


I.e. to verify the post condition:

   (index between: 1 and: self size)
      implies: (self at: index) == detectedCharacterOfInterest


{Note: Taking the problem description at face value, here.
        Whether any of this holds up is left to OA.
}



> - Microsoft: out of habit?


Not this time, it seems.


> - K&R: for promoting zero-terminating strings?


Nothing wrong with zero-terminating.
Good results can be had, even when
such notions are used consistently.


>
> Mostly I blame Borland for making the access to Paradox tables
> so heavily dependent on so easily corruptible indices. That's
> where the unexpected file contents come from ...


If you like.
I've found that holding the flashlight where
I can expect to detect any errant translations
from some man-in-the-middle phase change, in the
off chance there is one, pans out surprisingly often.

;-)


Regards,

-cstb

On Wed, 03 Nov 2004 21:54:05 -0800,
cstb <[hidden email]> wrote:
the code was just exporting query results into some
text based format ... the \0's appeared because of
corrupt indices.

As Ian pointed out, OA fixed this behaviour in a patch,
which somehow was not installed in this dev image ...

Funny thing: I just noticed that the deployed application
would not have suffered this bug, as it's created by a
"virgin" 5.1.4 image.

How's that for a change: "Help! I see a bug in the IDE which
goes away in the exe!" :-)

>
> >- Microsoft: out of habit?
>
> Not this time, it seems.

If I strained myself I could accuse them for providing a runtime
function which makes error checking hard.

> >- K&R: for promoting zero-terminating strings?
>
> Nothing wrong with zero-terminating.
> Good results can be had, even when
> such notions are used consistently.

Lately I'm all in favor of counted strings ... with a sufficiently
large count word, of course.

I've had really strange results, when I tried to access
Paradox tables from outside the BDE. The stock ODBC driver
got easily confused upon the simplest joins and happily
delivered wrong results. It would have caused a major
desaster here, producing 10.000 booklets with unreliable
information in them...

Thanks for your comments,
s.