On Mon, 19 Feb 2018, Martok via Lazarus wrote:

Am 19.02.2018 um 00:18 schrieb Michael Van Canneyt via Lazarus:
Why is it obviously not true ? It's obviously not true that it is compatible
at the binary level. FPC does not produce the same binary code
I'm more talking about the macroscopic perspective. Of course the binary code
may be different, but does it have the same concept of what a specific block of
source "means"?

It should.

It's obvious that if CloseFile() under the hood actually does nothing, this
is not what it 'means'.

The examples you give are in a gray zone, where "what it means" is not always so
clear.


Or, put differently,
But source code written for Delphi must compile in FPC.
Should it also do something *similar*?

Do you have examples where it does not ?


Just from the things that come up at least twice a year in the time since I
started actively following the lists... tempvar allocation and lifetimes
(especially with respect to interface refcounting), TBitmap Pixelformat & co,
LCL event order, my pet peeve small type memory layout...
I get why most of them are/must be different, it's just that code compiles, but
stops working. That's kinda the opposite of what the technical definition of
"source-code compatible" means.

Really? Where did you find this definition ?

If your code relies on implementation details, it won't always work obviously.

But if you spot differences in behaviour, you can notify the devs. There are
then 2 options:
- They try to fix the behaviour.
- They explain why it works differently.

And that's all there is to say about it.

Michael.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Reply via email to