[fpc-devel] Freepascal in microcontrollers

[Jonas Maebe]

On 28 Feb 2008, at 11:17, Daniël Mantione wrote:

> Op Thu, 28 Feb 2008, schreef Jonas Maebe:
>
>> It's not about Linux vs. Windows, it's about FPC 2.2.0 vs FPC  
>> 3.4.0, coupled with the fact that bitpacked records as currently  
>> defined are not usable for defining a specific layout.
>
> It compeletely normal that a record written by a a program written  
> in FPC 2.2 can be read be FPC 3.4.

A regularly packed record, yes. "Non-packed" records: not at all. In  
fact, their layout changed in some circumstances in FPC 2.3.1 compared  
to earlier versions. As to bitpacked records:

> If you design a feature, after a grace time, it should be kept  
> backward compatible.

Not if they are described like this in the manual (ref.tex, line 1204):

***
Note that the internals of the bitpacking are opaque: they can change  
at any time in the future. What is more: the internal packing depends  
on the endianness of the platform for which the compilation is done,  
and no conversion between platforms is possible. This makes bitpacked  
structures unsuitable for storing on disk or transport over networks.  
The format is however the same as the one used by the GNU Pascal  
Compiler, and we aim to retain this compatibility in the future.
***

The same goes for the internal format of sets (which also changed a  
while ago), and should also go for the layout (as far as the part  
which is normally invisible to the programmer goes) and reference  
counting of ansistrings/interfaces etc.

> I haven't heard the argument why bitpacked records should be exempt  
> from this.

Because they were not designed/implemented with binary portability/ 
compatibility in mind, and doing so allows freedom to optimize them,  
make them compatible on any platform with the custom format there if  
any (e.g. how debuggers expect them to be laid out), etc.

If you don't have to fix something in concrete, it's always a good  
idea not to do so because it'll only come back later to haunt you.  
That does not mean you have to actively try to change every opaque  
structure in every release in order to break backwards compatibility,  
but it does give you the freedom to do so when it's useful.

As I said before: if you want to define something which has a  
predictable layout, you have to do so specifically and give the  
programmer the means to do so. If it is not clear what the compiler  
will/may do from just reading the declaration and active compiler  
directives, it's almost by definition improper to rely on any current  
implementation details.


Jonas