Functions that return structures

[ASerge]

As I stated in a previous post, I don't think FPC should replicate Delphi's bugs/errors.

This is not Delphi. This is an incompatibility between the C++ and C compilers from Microsoft.
For example -cstruct-out.

[440bx]

As I stated in a previous post, I don't think FPC should replicate Delphi's bugs/errors.

This is not Delphi. This is an incompatibility between the C++ and C compilers from Microsoft.
For example -cstruct-out.

It is about Delphi, the comment in  the compiler clearly shows it is.

The incompatibility between C and C+ compiler from MS is a separate issue and, unfortunately, FPC should replicate that problem because that issue has determined what the Win32 ABI is.  Like it or not, a compiler should implement the ABI even if it is not fully consistent.

[ASerge]

It is about Delphi, the comment in  the compiler clearly shows it is.

No. The developers of the Microsoft compilers for C and C++ have chosen different approaches to returning small records.
Given that most Windows used C++, all other compilers used the same approach to comply. Based on this, for compatibility, many will consider the option when returning via eax:edx to be a bug.

[440bx]

@Serge,

You need to read @PascalDragon's post
https://forum.lazarus.freepascal.org/index.php/topic,71231.msg556146.html#msg556146

Half the mess is because FPC followed Delphi's mistake.  The other half of the mess is because MS C++ didn't follow the Win32 ABI.   There are two mistakes, one by Delphi replicated by FPC and another one by MS.

FPC got into the mess by following Delphi.

[gues1]

Half the mess is because FPC followed Delphi's mistake.  The other half of the mess is because MS C++ didn't follow the Win32 ABI.   There are two mistakes, one by Delphi replicated by FPC and another one by MS.
FPC got into the mess by following Delphi.

Microsoft, that propose this ABI, HAVE DONE a solution for this (23 years ago  ) : USE A INT64.

This is. Other streets may lead in a hell and will break all old code.

And except for a couple of functions ABSOLUTE DEPRECATED from Microsoft (they understood that stupid thing), I don't think Microsoft has produced any other APIs with such features.

A part that speaking about ABI is a nonsense, 'cause the compiler consent the use of some "directive" that modify the same ABI interface (in addition to those already mentioned there is the "NAKED" which says it all).

[440bx]

Microsoft, that propose this ABI, HAVE DONE a solution for this (23 years ago  ) : USE A INT64.

There are two problems with that.
1. it is only available to compilers that support 64 bit.  (sometimes it is necessary to use a legacy compiler to deal with legacy code.)
2. In this particular case, we are talking about a structure and throwing away half its definition isn't what should be done. 

In this particular case, the structure has a HighPart and a LowPart fields, those should not be thrown away because some compiler isn't implemented correctly.

[gues1]

1. it is only available to compilers that support 64 bit.  (sometimes it is necessary to use a legacy compiler to deal with legacy code.)

If you have to use old compilers, the new change will not help. I don't think the FPC team will make any changes to old compilers.
Instead, INT64 has been implemented in all compilers for years now.

2. In this particular case, we are talking about a structure and throwing away half its definition isn't what should be done. 
In this particular case, the structure has a HighPart and a LowPart fields, those should not be thrown away because some compiler isn't implemented correctly.

By using INT64 (or UINT64) you lose nothing.

[440bx]

By using INT64 (or UINT64) you lose nothing.

That's simply not true.  You lose the representation of the data type as being made of a LowPart and a HighPart.

Workarounds are NOT solutions.

[gues1]

Workarounds are NOT solutions.

It's not a workaround, it's the only solution that Microsoft (who makes those functions in this way) give us. Not other suggest were given. They don't sayd "use an WIN32 ABI compliant compiler" ... they give us this solution. Other workaround for old compilers is to construct a specific function in ASSEMBLER that grab the data (I mean "reincapsulate" the original function).

None wil modify old compilers (how many ? 1, 2, 3 .....)  to adhere this. It's a dead discussion.

A reflection, may be OT .... but:

my thought, and not only because it's what I do, is that you can't abandon old projects and then pick them up again with old tools thinking that they can be radically "updated".
I bring ALL the projects developed on par with the development environments, of course with different times and methods, but I bring them ALL.
If a project can't be updated for various reasons (technological or other) I will redo it at the right time, BUT ALWAYS with the new tools (even if it means changing hardware).
Of course, I have a business and therefore behind what I do there is an economic coverage. And I use Delphi, not free tools like Lazarus for which I still face costs.

Every now and then I think it is necessary to "modernize" both the applications and the "thinking".

The oldest project still managed dates back to 2001, with the porting to 64 bits in 2012 and is a mixed C++ / Pascal project.

A project that is not managed but still exists and is compilable is on a disk inside a virtual machine, and is a mixed Delphi / VB project that dates back to 1997 (but I have no intention of maintaining it, I keep it as a permanent MUSEUM)