Ansistrings zero element

[anna]

I'm using Lazarus-0.9.29-27550-fpc-2.4.0-20101003-win32.exe

I don't remember when actually it was changed...

But previously this code works fine:

Code: [Select]

{$H+}  
var
  s:string;
begin
  s:='123';
  writeln(s[0]); {must display [b]1[/b]}
end.


Now I get error:
Error: Element zero of an ansi\wide- or longstring can't be accessed, use (set)length instead


Why?!?!

Zeroth element of shortstring contain its length not of ansistrings!!!

[anna]

It annoyed me, that I must always remember about UTF-ANSI convertion. But now I must monitor what is first element 0th or 1st in addition.

Developers, STOP strings changins!!!!!!!!!!!!!!

[theo]

The first character of an AnsiString has always been at position 1 afair!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is not new!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

;-)

[anna]

Please, run attached project. When execution will stop on a breakpoint, open Evaluate/Modify window and type s[0] and press Evaluate button

[cdbc]

@theo +1
@anna: get your facts strait before you wine!
Pascal strings have always been 1-based! 0-th element is a pointer to the entire string (memory alloc).
Regards Benny

[anna]

@theo +1
@anna: get your facts strait before you wine!

Regards Benny

Null-terminated strings always are zero-based.
AnsiString is a pointer so length may be more 64 KBytes.

[anna]

Pchar is also pointer. Pchar it seems to be correct .  Yet...

[Martin_fr]

string => always 1 based, always been
pchar => pointer-to-array-of-char => 0 based, arrays are 0 based by default

GDB:
@anna: you are right in gdb a[0] fo9r string works

but it's a bug.
GDB is a debugger originally written for C, not pascal. GDB has some ability to deal with any language, including pascal.

Unfortunately at current it's not possible to tell gdb that pascal strings are 1 based. Or maybe it is possible (dwarf 3), but not yet implemented.

So in gdb all string indices are wrong by 1.

And yes, it makes debugging strings very inconvenient. But there is no quick fix:
- dwarf3 is under development, it will one day be supported by fpc. and probably gdb supports it too. But it doesn;t look like anytime soon
- The alternative is to write an entire debugger from scratch. There are some projects, but again not even close to anytime soon.

[marcov]

@anna: you are right in gdb a[0] fo9r string works

Accessing element 0 of a string is supported for shortstring only. And in {$H+} string is not shortstring.

Moreover, even though it still supported (after 16 years legacy, since deprecated since TP/D1 times), one should always use length() and setlength() to get/set the length of strings.

This behaviour has been like that since 1997-98 when ansistring was introduced.

[Martin_fr]

@anna: you are right in gdb a[0] fo9r string works

Accessing element 0 of a string is supported for shortstring only. And in {$H+} string is not shortstring.

@marcov: Unfortunately you cut my quote short. I explained that in GDB due to a *bug* the first character in the string "a" is indeed returned by a[0].

In your example a[0] for shortstring is not the first char, but a special field containing the length of the string.

However Anna was asking for the first char in "a"

Code: [Select]

  writeln(s[0]); {must display [b]1[/b]}


and later pointed to the debugger as a >>working<< example of a[0]

open Evaluate/Modify window and type s[0] and press Evaluate button

[Marc]

unfortunately in the debug info, strings are encoded as pchar. So for gdb there is no difference between a pchar and a string, therefore the index starts at 0.
Lazarus cannot help here since it doesn't know if a pchar is a "real" pchar or a string