[Lazarus] Can't compile trunk with fpc 2.4.5 under ubuntu

[Marco van de Voort]

On Mon, Feb 27, 2012 at 09:51:41PM +0100, Martin Schreiber wrote:
> > If so, please also note 
> > the other interface related change:
> >
> > http://wiki.freepascal.org/User_Changes_Trunk
> >
> Thanks. The problem with some of the recent "Delphi compatibility" changes is 
> that it breaks Delphi 7 compatibility.

Well, if that is a "problem" is a matter of taste. In reality, I think that
D7 was wrong here, stuffing binary data into an ansistring.

True, if D2009 didn't change to unicodestring, it would probably be the most
minor issue, but still, wrong is wrong.

> MSEide+MSEgui version 2.6 is compilable and runs with Delphi 7, a good
> benchmark for FPC.  BTW, does current Delphi return pointer or tbytes in
> TDataset.Bookmark?

TBytes. Afaik it returned pointer from D2006..2007.

>  Does it allow pointer arithmetic with the new TDateset
> buffer type pbyte? 

D2009 does not allow this in default mode, but it does allow overindexing
like FPC when {$POINTERMATH ON} is added. In my work Delphi code, this is
default :-)

> Delphi 7 can do pointer arithmetic with pchar and pwidechar only. 

> A side mark: I don't think using the old ansistring as combined binary and
> character buffer is such a bad thing. 

I do think that is bad. If you start using ansistring in mixed encoding
environments (e.g. utf16 aka widestring/unicodestring), there is a danger of
mutilation.

This is currently not very noticable in FPC because the default type is
still ansistring[OS default 1-byte encoding], but we might not want to be
stuck with that forever.

> TByte could replace such buffers only if Pascal string indexing would be
> zero based. 

No, since tbookmark afaik never represented a true string, character access
would be meaningless, and would be a code smell indicating bad code.

> Consequently with all these changes Delphi string indexes should be zero
> based too, same as dynamic array indexes.

IMHO this is not one of the differences that is significant enough to
perpetuate workarounds till eternity. So I'm willing to entertain
workarounds with a scope of a FPC release or two, but not beyond.