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_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
