PCHAR Children's Question

[Nitorami]

My logic is different. A zero offset from the base, as the first index, makes much more sense

The reason why strings start at index 1 is because the original Pascal string was shortstring, with byte 0 encoding its length. That limited strings to a length of 255 but allowed very efficient string handling because no search for the termination character was required.
When support for other string types was added later, it was logical to keep the index 1, otherwise compatibility with the shortstrings would have been broken. That would have become a real mess.

[marcov]

My logic is different. A zero offset from the base, as the first index, makes much more sense

The reason why strings start at index 1 is because the original Pascal string was shortstring, with byte 0 encoding its length. That limited strings to a length of 255 but allowed very efficient string handling because no search for the termination character was required.

This is not true. Even before short/UCSD string, arrays (and thus strings) typically started at 1 in Pascal.

[MarkMLl]

This is not true. Even before short/UCSD string, arrays (and thus strings) typically started at 1 in Pascal.

With respect, that is not my recollection: I have /never/ seen a Pascal implementation which didn't have both the minimum and maximum index of an array specified explicitly, so there is no scope for any assumption regarding the starting index (i.e. 0 or 1) until open arrays could be passed as parameters... and even in that context I've not seen the minimum index defaulting to 1.

MarkMLl

[BrunoK]

Adding to marcov's comment.
If my memory doesn't fail, in the old days (> 40 years ago), in BASIC and COBOL arrays did start at indice 1 by default. COBOL was reigning as king in business applications but many people had a first contact to programming with BASIC.
In BASIC there was a directive "BASE 0" to supersede the array index basing but I think it appeared in later versions.

[MarkMLl]

Adding to marcov's comment.
If my memory doesn't fail, in the old days (> 40 years ago), in BASIC and COBOL arrays did start at indice 1 by default. COBOL was reigning as king in business applications but many people had a first contact to programming with BASIC.
In BASIC there was a directive "BASE 0" to supersede the array index basing but I think it appeared in later versions.

Yes, and in APL there's a quad or something that can be set. But as far as Pascal is concerned, J&W Ed4 p57 linked at https://wiki.freepascal.org/Pascal_User_Manual_and_Report explicitly uses ... in array declarations, except where the index is a subrange type.

My recollection is that J&W ed2 is the same, I can't remember what's said in Wirth earliest papers on Pascal which tend to be elusive.

Somewhat later: Wirth's 1971 description of the language at https://www.research-collection.ethz.ch/bitstream/20.500.11850/68712/1/eth-3290-01.pdf p19 explicitly specifies both the minimum and the maximum index of an array in its declaration. The examples use 1 as the minimum index, but there is no justification in assuming that the minimum index defaults to 1 (since there is no provision for a minimum index) or that element zero is unavailable.

I note that the slightly later https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68910/eth-3059-01.pdf still assumes /* */ as alternatives to { } (p50). However in other ways it's closer to "Pascal as she is spoke", i.e. "char" instead of "alfa", removal of "class" as a dynamic container, and so on.

MarkMLl

[PascalDragon]

Nevertheless, I consider it a perversion and illogical..... If "Copy" can NEVER be used for PCHAR, I can understand that, then it's easier to remove it for that type, otherwise it's a bug...

A PChar in a Copy is implicitly converted to a AnsiString. You would see this if instead of doing a Writeln of the Copy's result you'd try to assign it to a PChar variable instead which will fail. And due to this you must use 1-based indexing as mentioned in the documentation (and yes, this behavior is compatible with Delphi).

And the incomprehensible things with this function are still there.... Maybe there is a problem with its implementation for all strings after all?

There is nothing incomprehensible about this function. You just need to keep in mind that start indices smaller than 1 are clamped to 1 and counts that reach behind the length of the string are clamped accordingly as well.

The "bug", if it can be called that, is the conversion pchar->string silently done by the compiler but, it's probably needed for Delphi compatibility.

There is {$modeSwitch pCharToString‑} if you don’t like that. However, I can’t observe any difference. Does this mode switch have any effect? Show me some code.

As far as I can see that modeswitch isn't referenced anywhere inside the compiler. I don't know if it ever was or what it was originally intended for...

@beria,

What you showed in your example, quite likely is related to the problem discussed in the following thread: https://forum.lazarus.freepascal.org/index.php/topic,48133.msg346158.html#msg346158

You are right. But I still think it's a mistake, even if it's done for Delphi compatibility, it doesn't have to work that way outside of that compatibility...

It's less error prone to make the intrinsic behave the same across all modes. Also now this behavior is also required for backwards compatibility.

I'm not saying it's a comfortable situation: now that a string's element zero is no longer directly equivalent to the length the distinction between Pascal-style strings and dynamic arrays is very unfortunate: however it's there, it's not likely to change, and it's best keeping your use of Pascal- and C-style strings separate.

One can always use $ZeroBasedStrings On (though that will not change the behaviour of Copy).

[MarkMLl]

I'm not saying it's a comfortable situation: now that a string's element zero is no longer directly equivalent to the length the distinction between Pascal-style strings and dynamic arrays is very unfortunate: however it's there, it's not likely to change, and it's best keeping your use of Pascal- and C-style strings separate.

One can always use $ZeroBasedStrings On (though that will not change the behaviour of Copy).

I'm happy enough with zero being reserved... although my comments in another thread (not strictly Pascal) apply. But I can sympathise with people who get here from C++ etc., which only gained any sort of string type (as distinct from char array) comparatively recently.

MarkMLl