Hi,

The 3rd unit test fails due to StrPos giving a access violation. I ran this same unit test under Delphi 7 and it passed as StrPos returned a nil value when passing two '' param values.

Has this been reported as a bug yet?

-----------------  CUT  -------------------
var
   lFrom: string;
   lSearch: string;
   lResult: PChar;
begin
   lFrom   := 'abc';
   lSearch := 'b';
   lResult := StrPos(Pointer(lFrom), Pointer(lSearch));
   AssertEquals('Failing on 1', 'bc', string(lResult));
   lSearch := 'x';
   lResult := StrPos(Pointer(lFrom), Pointer(lSearch));
   AssertEquals('Failing on 2', '', string(lResult));
   lFrom   := '';
   lSearch := '';
   lResult := StrPos(Pointer(lFrom), Pointer(lSearch));
   AssertEquals('Failing on 3', '', string(lResult));

----------------- END -------------------

Regards,
- Graeme -

Hi

Forgot to mention, I ran this using:
Free Pascal Compiler version 2.0.1 [2005/10/02] for i386 on Windows 2000

G.

Hi,

I put a breakpoint inside StrPos and stepped through the code. It raised a "External SIGSERV" error on the second line:

   p:=strscan(str1,str2^);

I don't understand assembler so couldn't debug into StrScan.

Regards,
- Graeme -

Graeme Geldenhuys wrote

lFrom := ''; lSearch := ''; lResult := StrPos(Pointer(lFrom), Pointer(lSearch)); AssertEquals('Failing on 3', '', string(lResult));

No. I've fixed it and added a test. You can check whether something has been reported as a bug by going to
http://www.freepascal.org/bugs.html

If possible, a copy of your unit tests would be nice addition to our test suite.

Jonas

Eeeeuwww....

StrPos is expecting 2 PChar params and not a Pointer. Please use PChar(lFrom) and PChar(lSearch) to let the compiler make the proper string to PChar conversion.
You never ever can cast a string to a pchar using Pointer()

Marc

Jonas Maebe wrote

No. I've fixed it and added a test. You can check whether something has been reported as a bug by going to http://www.freepascal.org/bugs.html

Thanks for that!

If possible, a copy of your unit tests would be nice addition to our test suite.

I will go through the unit and see what is appropriate. The unit I am working through now is like a coders toolbox, a bunch of utility fuctions.

In this test case we used our own implementation of StrPos, as Delphi's one is dog slow. Written in assembler, but slow nonetheless. Good news is that Free Pascal's implementation is even faster than ours. :-)

Regards,
- Graeme -

Marc Weustink wrote

StrPos is expecting 2 PChar params and not a Pointer. Please use PChar(lFrom) and PChar(lSearch) to let the compiler make the proper string to PChar conversion. You never ever can cast a string to a pchar using Pointer()

I see your point, and amended my code. Nonetheless, Delphi never through a AV. I see Jonas created a fix for it though.

Regards,
- Graeme -

It is very dangerous to rely on undocumented behaviour. At least the TP documentation does not specify what happens if you pass a null pchar to strpos, I don't know about Delphi. If you typecast an ansistring to a pchar, then the compiler makes sure that if the ansistring is empty (and thus a null pointer), a valid pointer to an empty null-terminated string is returned.

Jonas

Jonas Maebe wrote

strpos, I don't know about Delphi. If you typecast an ansistring to a pchar, then the compiler makes sure that if the ansistring is empty (and thus a null pointer), a valid pointer to an empty null-terminated string is returned.

Is that not also undocumented behaviour ?

Micha

I'm quite sure it isn't: afaik typecasting an ansistring to a pchar is fully supported. This means that an empty ansistring must result in an empty (as opposed to an invalid) pchar.

Jonas

its documented somewhere in the delphi help iirc

It's explicitly stated in the docs.

Michael.

Taken from Delphi 7 help:

Mixing Delphi strings and null-terminated strings

* You can also use Pointer(S) to cast a long string to an untyped pointer. But if S is empty, the typecast returns nil.
* PChar(S) always returns a pointer to a memory block; if S is empty, a pointer to #0 is returned.

Regards,
- Graeme -

Thanks, that is very ugly. That means that PChar(Pointer(MyStr)) is not the same as PChar(MyStr) which is not very pascalish IMHO, but ok.

I can understand that PChar(MyStr) to always return a valid pointer is a desirable property of course, but why not use a function instead that does this ? Useless question, of course.

Micha

It happens in more in Pascal. For example, single(longint_var) is also not the same as single(pointer(longint_var)) (let's assume a 32bit system). In the former case, the longint is convert to a floating point number with the same value. In the latter case, you get a floating point number with the same bit pattern as that original longint (which may be a valid or invalid floating point number, and whose value is almost certainly different from the longint's value, except in case of 0).

Jonas

Oh, I thought always the second case happened. Apparantly not.

Micha

No, otherwise an implicit type conversion (e.g. passing a longint to a function which expects a floating point parameter) and an explicit typecase (as above) would have different results. Implicit type conversions are not always allowed (because of type safety), but when they are allowed they have the same effect as an explicit typecast.

Jonas