const records passed incorrectly

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

const records passed incorrectly

Anthony Walter-3
Hi all. I am new to fpc and linux in general, though I do have a long
time experience with Delphi.

I was writing some code basic system (using the libc library) when I
ran across the following  problem .. some code:

const
  libc = 'libc.so.6';

type
  TTimeSpec = record
    Sec: Cardinal;  { Seconds }
    NSec: Cardinal; { Nanoseconds }
  end;
  PTimeSpec = ^TTimeSpec;

function nanosleep(const RequestedTime: TTimeSpec; Remaining:
PTimeSpec): Integer; cdecl; external libc;

The problem with fpc and the above import is with the RequestedTime
parameter, declared as a const record. In Delphi declaring a const
record parameter cause the compiler to generate code to pass the
record by reference (that is to say passing the address). In fpc,
however this is not happening.

My question is why. Why isn't fpc generating the code to pass a const
record as a reference?

I can find tons of WinAPI code where records are passed as const
references by Delphi. I see this issue causing me some headaches as I
port my Delphi code to run across platforms using fpc.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Michael Van Canneyt


On Sun, 15 Nov 2009, Anthony Walter wrote:

> Hi all. I am new to fpc and linux in general, though I do have a long
> time experience with Delphi.
>
> I was writing some code basic system (using the libc library) when I
> ran across the following  problem .. some code:
>
> const
>  libc = 'libc.so.6';
>
> type
>  TTimeSpec = record
>    Sec: Cardinal;  { Seconds }
>    NSec: Cardinal; { Nanoseconds }
>  end;
>  PTimeSpec = ^TTimeSpec;
>
> function nanosleep(const RequestedTime: TTimeSpec; Remaining:
> PTimeSpec): Integer; cdecl; external libc;
>
> The problem with fpc and the above import is with the RequestedTime
> parameter, declared as a const record. In Delphi declaring a const
> record parameter cause the compiler to generate code to pass the
> record by reference (that is to say passing the address). In fpc,
> however this is not happening.

No.

It is nowhere written in the Delphi specs that const parameters
are passed by reference. It is often so, but is by no means guaranteed.

If you want to pass it as a reference, you should use var. Not const.

Const means that the called procedure does not change the contents.
The compiler may then decide to pass it by reference if it is more
advantageous to do so, but it is not a rule that this is done.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
Actually the help does. The first thing I did when I got to work with
morning was top open my Delphi 7 help file and typed "const" then
choose the topic "constant (const) parameters".

Quote:

"Using const allows the compiler to optimize code for structured- and
string-type parameters."

Using const with string type and structured types causes a known
optimization to pass references rather than copies on the stack. The
key is Delphi checks code in the callee making sure you don't try to
write to the const parameter.

This is useful not only for speed purposes, but for operability with C
code like below (take from the Windows Platform SDK help file):

BOOL RectVisible(
    HDC hdc, // handle of the device context
    CONST RECT *lprc // address of rectangle structure
   );

Delphi declares this import as follows:

function RectVisible(DC: HDC; const Rect: TRect): BOOL; stdcall;

Note the "const Rect: TRect"

Now I wrote an example to test the differences between FPC (version
2.2.4) and Delphi (version 7). I found something interesting, please
read the results at the bottom.

Code:

program test;

{$APPTYPE CONSOLE}

type
  TRect = record
    Left, Top, Right, Bottom: Integer;
  end;

procedure A(const R: TRect; P: Pointer);
begin
  if @R = P then
    WriteLn('R refers to a reference on the stack')
  else
    WriteLn('R is a structure on the stack');
end;

procedure B;
var
  R: TRect;
begin
  A(R, @R);
end;

begin
  B;
end.

Output:

FPC: "R refers to a reference on the stack"
Delphi: "R refers to a reference on the stack"

Which is exactly correct with both compilers. So there is no problem,
my original problem doesn't apply.

***** BUT *****

There is a problem with the above code on FPC when you change calling
conventions of A.

If you change the calling convention to stdcall it still works, no
problem. Both FPC and Delphi output "R refers to a reference on the
stack."

On the other hand, changing to cdecl breaks things on the FPC side.

procedure A(const R: TRect; P: Pointer); cdecl;

Output:

FPC: "R is a structure on the stack"
Delphi: "R refers to a reference on the stack"

See, FPC is now working differently. This is causing me headaches when
I am writing code to import libc (which uses cdecl).

I believe FPC is in error when it is generating code to pass const
structures (which I've tested). It handles parameters one way with
fastcall, stdcall, pascal (which I believe is the correct way), and a
different way with cdecl.

I've tested Delphi and it always uses a reference on the stack with
all calling conventions using the code above.

I've provided the information from the Delphi help file which
documents this feature.

On Mon, Nov 16, 2009 at 2:59 AM, Michael Van Canneyt
<[hidden email]> wrote:

>
>
> On Sun, 15 Nov 2009, Anthony Walter wrote:
>
>> Hi all. I am new to fpc and linux in general, though I do have a long
>> time experience with Delphi.
>>
>> I was writing some code basic system (using the libc library) when I
>> ran across the following  problem .. some code:
>>
>> const
>>  libc = 'libc.so.6';
>>
>> type
>>  TTimeSpec = record
>>   Sec: Cardinal;  { Seconds }
>>   NSec: Cardinal; { Nanoseconds }
>>  end;
>>  PTimeSpec = ^TTimeSpec;
>>
>> function nanosleep(const RequestedTime: TTimeSpec; Remaining:
>> PTimeSpec): Integer; cdecl; external libc;
>>
>> The problem with fpc and the above import is with the RequestedTime
>> parameter, declared as a const record. In Delphi declaring a const
>> record parameter cause the compiler to generate code to pass the
>> record by reference (that is to say passing the address). In fpc,
>> however this is not happening.
>
> No.
>
> It is nowhere written in the Delphi specs that const parameters
> are passed by reference. It is often so, but is by no means guaranteed.
>
> If you want to pass it as a reference, you should use var. Not const.
>
> Const means that the called procedure does not change the contents.
> The compiler may then decide to pass it by reference if it is more
> advantageous to do so, but it is not a rule that this is done.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Martin Schreiber
In reply to this post by Michael Van Canneyt
On Monday 16 November 2009 08:59:50 Michael Van Canneyt wrote:
>
> It is nowhere written in the Delphi specs that const parameters
> are passed by reference. It is often so, but is by no means guaranteed.
>
There is a sentence in Delphi 7 "Language Guide" in chapter 12 "Parameters and
function results" which possibly belongs to the theme:
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/programcontrolov_xml.html
"
Value and constant (const) parameters are passed by value or by reference,
depending on the type and size of the parameter:
[...]
Sets, records, and static arrays of 1, 2, or 4 bytes are passed as 8-bit,
16-bit, and 32bit values. Larger sets, records, and static arrays are passed
as 32-bit pointers to the value. An exception to this rule is that records
are always passed directly on the stack under the cdecl, stdcall, and
safecall conventions; the size of a record passed this way is rounded upward
to the nearest double-word boundary.
"
An example from Delphi windows.pas:
"
type
  POverlapped = ^TOverlapped;
  _OVERLAPPED = record
    Internal: DWORD;
    InternalHigh: DWORD;
    Offset: DWORD;
    OffsetHigh: DWORD;
    hEvent: THandle;
  end;
  {$EXTERNALSYM _OVERLAPPED}
  TOverlapped = _OVERLAPPED;
  OVERLAPPED = _OVERLAPPED;
  {$EXTERNALSYM OVERLAPPED}
[...]
function LockFileEx(hFile: THandle; dwFlags, dwReserved: DWORD;
  nNumberOfBytesToLockLow, nNumberOfBytesToLockHigh: DWORD;
  const lpOverlapped: TOverlapped): BOOL; stdcall;
"
And the C++-header:
"
BOOL WINAPI LockFileEx(
  __in        HANDLE hFile,
  __in        DWORD dwFlags,
  __reserved  DWORD dwReserved,
  __in        DWORD nNumberOfBytesToLockLow,
  __in        DWORD nNumberOfBytesToLockHigh,
  __inout     LPOVERLAPPED lpOverlapped
);
"
So it is stdcall -> "An exception to this rule is that records are always
passed directly on the stack" but LPOVERLAPPED is a pointer? There is a not
documented special rule for const?

Please don't shot me if it does not belong to the theme. ;-)

Martin
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Jonas Maebe-2
In reply to this post by Anthony Walter-3

On 16 Nov 2009, at 14:50, Anthony Walter wrote:

> There is a problem with the above code on FPC when you change calling
> conventions of A.

Const indeed behaves differently depending on the calling convention.  
With register and stdcall, we emulate Delphi. With mwpascal, we  
emulate MetroWerks Pascal. With cdecl, we emulate C compilers. In C  
compilers, adding "const" does not change the way the parameter is  
passed: they are still passed by value. There have been lots of  
discussions in the past about adding something like constvar or  
constref, but nothing has ever come from it.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
In reply to this post by Martin Schreiber
I assume you replied so quickly you did not get the chance to read my
crafted and tested reply. You may have been typing the same time I was
:)

Please go back and read my message and note the tests section.

Jonas, why is FPC emulating C when it could simply follow the Delphi
way and prevent these incompatibilities?

It seems to me that the most logical thing is to handle it the same in
all calling conventions, which is what Delphi does (as verified
through my tests).

On Mon, Nov 16, 2009 at 8:54 AM, Martin Schreiber <[hidden email]> wrote:

> On Monday 16 November 2009 08:59:50 Michael Van Canneyt wrote:
>>
>> It is nowhere written in the Delphi specs that const parameters
>> are passed by reference. It is often so, but is by no means guaranteed.
>>
> There is a sentence in Delphi 7 "Language Guide" in chapter 12 "Parameters and
> function results" which possibly belongs to the theme:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/programcontrolov_xml.html
> "
> Value and constant (const) parameters are passed by value or by reference,
> depending on the type and size of the parameter:
> [...]
> Sets, records, and static arrays of 1, 2, or 4 bytes are passed as 8-bit,
> 16-bit, and 32bit values. Larger sets, records, and static arrays are passed
> as 32-bit pointers to the value. An exception to this rule is that records
> are always passed directly on the stack under the cdecl, stdcall, and
> safecall conventions; the size of a record passed this way is rounded upward
> to the nearest double-word boundary.
> "
> An example from Delphi windows.pas:
> "
> type
>  POverlapped = ^TOverlapped;
>  _OVERLAPPED = record
>    Internal: DWORD;
>    InternalHigh: DWORD;
>    Offset: DWORD;
>    OffsetHigh: DWORD;
>    hEvent: THandle;
>  end;
>  {$EXTERNALSYM _OVERLAPPED}
>  TOverlapped = _OVERLAPPED;
>  OVERLAPPED = _OVERLAPPED;
>  {$EXTERNALSYM OVERLAPPED}
> [...]
> function LockFileEx(hFile: THandle; dwFlags, dwReserved: DWORD;
>  nNumberOfBytesToLockLow, nNumberOfBytesToLockHigh: DWORD;
>  const lpOverlapped: TOverlapped): BOOL; stdcall;
> "
> And the C++-header:
> "
> BOOL WINAPI LockFileEx(
>  __in        HANDLE hFile,
>  __in        DWORD dwFlags,
>  __reserved  DWORD dwReserved,
>  __in        DWORD nNumberOfBytesToLockLow,
>  __in        DWORD nNumberOfBytesToLockHigh,
>  __inout     LPOVERLAPPED lpOverlapped
> );
> "
> So it is stdcall -> "An exception to this rule is that records are always
> passed directly on the stack" but LPOVERLAPPED is a pointer? There is a not
> documented special rule for const?
>
> Please don't shot me if it does not belong to the theme. ;-)
>
> Martin
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Jonas Maebe-2

On 16 Nov 2009, at 15:01, Anthony Walter wrote:

> Jonas, why is FPC emulating C when it could simply follow the Delphi
> way and prevent these incompatibilities?

I think that FPC's behaviour predates the existence of Delphi.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Michael Van Canneyt
In reply to this post by Anthony Walter-3


On Mon, 16 Nov 2009, Anthony Walter wrote:

> Actually the help does. The first thing I did when I got to work with
> morning was top open my Delphi 7 help file and typed "const" then
> choose the topic "constant (const) parameters".

Definitely not in the printed manual of D7, which I consulted prior
to typing my answer...

>
> Quote:
>
> "Using const allows the compiler to optimize code for structured- and
> string-type parameters."

Yes, it says this in my manual as well, but no more and no less.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
In reply to this post by Jonas Maebe-2
As I said in my introduction. I am new to Linux and FPC. I've used
them both for maybe 8 years, but not seriously.

On the Linux side for years I've just used it for minimal compiling
and a lot of web browser.

On the FPC I've fired it up from time to time over the years (and read
the website, mailing lists).

None of that I consider real use, just casual poking around.

But now I am taking a serious stab at porting my Windows OpenGL game
engine to a cross platform Windows, Linux, and Mac engine. I feel like
I am actually doing something real with Linux and FPC for the first
time.

One thing I've noticed about the FPC community which has me a somewhat
apprehensive is a bit of a particular attitude I've picked up on.

A few times now I've read comments by or had conversations with people
in the FPC community who have explained incompatibilities away using
the phrase:

"FreePascal did this before something else so we shouldn't change"

Forgetting the whole argument about who was actually first, I have to
ask what difference does it make?

Why does doing something first make it written in stone. It seems a
bit childish to say, "No way, I way here first, I won't budge. You
move."

Really, that attitude is quite the turn off.

There there these incompatibilities causing me to avoid language
features. I'd like to use them but just won't (Operator overloading
and generics come to mind), mostly because I really don't want to have
ifdefs all over the place.

In my opinion, there is an incompatibility. Fix it.

On Mon, Nov 16, 2009 at 9:03 AM, Jonas Maebe <[hidden email]> wrote:

>
> On 16 Nov 2009, at 15:01, Anthony Walter wrote:
>
>> Jonas, why is FPC emulating C when it could simply follow the Delphi
>> way and prevent these incompatibilities?
>
> I think that FPC's behaviour predates the existence of Delphi.
>
>
> Jonas
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Florian Klämpfl
>
> In my opinion, there is an incompatibility. Fix it.

If you care about it, provide a usable patch.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
I probably should, but I've never worked on a community project
before. I don't know the ins and outs of hooking up to the developer
repository, getting the build environment working, discussing and
submitting my changes, testing those changes, and moving them into the
official version.

If anyone could provide me with links to that info you might have
yourselves another human resource on the fpc team.

On Mon, Nov 16, 2009 at 9:32 AM, Florian Klaempfl
<[hidden email]> wrote:
>>
>> In my opinion, there is an incompatibility. Fix it.
>
> If you care about it, provide a usable patch.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Michael Van Canneyt
In reply to this post by Anthony Walter-3


On Mon, 16 Nov 2009, Anthony Walter wrote:

> As I said in my introduction. I am new to Linux and FPC. I've used
> them both for maybe 8 years, but not seriously.
>
> On the Linux side for years I've just used it for minimal compiling
> and a lot of web browser.
>
> On the FPC I've fired it up from time to time over the years (and read
> the website, mailing lists).
>
> None of that I consider real use, just casual poking around.
>
> But now I am taking a serious stab at porting my Windows OpenGL game
> engine to a cross platform Windows, Linux, and Mac engine. I feel like
> I am actually doing something real with Linux and FPC for the first
> time.
>
> One thing I've noticed about the FPC community which has me a somewhat
> apprehensive is a bit of a particular attitude I've picked up on.
>
> A few times now I've read comments by or had conversations with people
> in the FPC community who have explained incompatibilities away using
> the phrase:
>
> "FreePascal did this before something else so we shouldn't change"
>
> Forgetting the whole argument about who was actually first, I have to
> ask what difference does it make?
>
> Why does doing something first make it written in stone. It seems a
> bit childish to say, "No way, I way here first, I won't budge. You
> move."
>
> Really, that attitude is quite the turn off.

Correct, but then the same applies to Borland/Codegear/Embarcadero.

Go ahead, and ask them to be more FPC compliant.

It'll be interesting to see their reaction.

People take such a position from Borland, but not from FPC. Why ?

This is quite ironic, because you PAY Borland and you put up with their
attitudes. You don't pay FPC but you also don't want to put up with our
attitudes. Where is the logic in that ? I would expect the opposite.
You pay them for god's sake, so they should do your bidding...

In reality it's always the FPC team that is f*d when an incompatibility arises.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Marco van de Voort
In reply to this post by Anthony Walter-3
In our previous episode, Anthony Walter said:
> I probably should, but I've never worked on a community project
> before. I don't know the ins and outs of hooking up to the developer
> repository, getting the build environment working, discussing and
> submitting my changes, testing those changes, and moving them into the
> official version.
>
> If anyone could provide me with links to that info you might have
> yourselves another human resource on the fpc team.

http://www.stack.nl/~marcov/buildfaq.pdf

details level 0.
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Jonas Maebe-2
In reply to this post by Anthony Walter-3

On 16 Nov 2009, at 15:29, Anthony Walter wrote:

> "FreePascal did this before something else so we shouldn't change"
>
> Forgetting the whole argument about who was actually first, I have to
> ask what difference does it make?

I was merely answering your question why we do it differently than  
Delphi, even though Delphi is generally the de facto standard. I was  
trying to explain that we did not do it differently simply because our  
way was the right one and Delphi's way the wrong one, or out of spite  
or so. But it appears that you interpreted my answer in exactly the  
opposite sense (that we won't change it out of spite).

The main problem with changing it now would obviously be that it would  
break backwards compatibility with existing code. It could still be  
done in Delphi mode onlu, of course, but changing the behaviour of a  
calling convention (which is normally an ABI issue) based on a  
language syntax mode feels... not right.

> There there these incompatibilities causing me to avoid language
> features. I'd like to use them but just won't (Operator overloading
> and generics come to mind), mostly because I really don't want to have
> ifdefs all over the place.

It's a lot of work to re-implement everything afterwards according to  
how Borland decided to implement things. Our time is finite, just like  
everyone else's... And generally people prefer to spend their time on  
implementing new features (that Borland again can add a few months/
year later using an incompatible syntax/behaviour ;) rather than on  
overhauling existing ones, or on Delphi features that we do not  
support at all yet.

In general, Delphi syntax is usually integrated/supported after a  
while anyway (because someone submits a patch, or because it becomes  
widely used and someone wants to use code that uses this feature).  
Like most community-driven open source projects, the way FPC evolves  
is primarily driven by
a) the interests of its core developers
b) the interest of other people that submit patches

There is no company (yet?) that writes FPC patches for commercially  
supporting Delphi developers, afaik. The closest there is, is http://wiki.freepascal.org/Bounties


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
In reply to this post by Michael Van Canneyt
This is because Delphi belongs to is a commercial enterprise, and it
is in their best interested not to bend over backwards to work with a
free competing product.

The power I felt FPC has had was it's compatibility with Delphi. FPC
maintained compatibility with the languages and even with the class
library (SysUtils.pas, Classes.pas).

I understand it's difficult to maintain this parity between FPC and
Delphi, especially when Delphi does things which seem wrong (such as
they way they implemented operator overloading), but IMO keeping that
parity goes is more important than ego (if that is where the problem
really lays).

To Marco:

Thanks for that link. I will read that rocument and try to get started
with the developer repository and build environment this week. If I
have and questions (which google and my own experimentation can't
answer), where would be the best place to submit them?

On Mon, Nov 16, 2009 at 9:41 AM, Michael Van Canneyt
<[hidden email]> wrote:

>
>
> On Mon, 16 Nov 2009, Anthony Walter wrote:
>
>> As I said in my introduction. I am new to Linux and FPC. I've used
>> them both for maybe 8 years, but not seriously.
>>
>> On the Linux side for years I've just used it for minimal compiling
>> and a lot of web browser.
>>
>> On the FPC I've fired it up from time to time over the years (and read
>> the website, mailing lists).
>>
>> None of that I consider real use, just casual poking around.
>>
>> But now I am taking a serious stab at porting my Windows OpenGL game
>> engine to a cross platform Windows, Linux, and Mac engine. I feel like
>> I am actually doing something real with Linux and FPC for the first
>> time.
>>
>> One thing I've noticed about the FPC community which has me a somewhat
>> apprehensive is a bit of a particular attitude I've picked up on.
>>
>> A few times now I've read comments by or had conversations with people
>> in the FPC community who have explained incompatibilities away using
>> the phrase:
>>
>> "FreePascal did this before something else so we shouldn't change"
>>
>> Forgetting the whole argument about who was actually first, I have to
>> ask what difference does it make?
>>
>> Why does doing something first make it written in stone. It seems a
>> bit childish to say, "No way, I way here first, I won't budge. You
>> move."
>>
>> Really, that attitude is quite the turn off.
>
> Correct, but then the same applies to Borland/Codegear/Embarcadero.
>
> Go ahead, and ask them to be more FPC compliant.
>
> It'll be interesting to see their reaction.
>
> People take such a position from Borland, but not from FPC. Why ?
>
> This is quite ironic, because you PAY Borland and you put up with their
> attitudes. You don't pay FPC but you also don't want to put up with our
> attitudes. Where is the logic in that ? I would expect the opposite. You pay
> them for god's sake, so they should do your bidding...
>
> In reality it's always the FPC team that is f*d when an incompatibility
> arises.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Michael Van Canneyt


On Mon, 16 Nov 2009, Anthony Walter wrote:

> This is because Delphi belongs to is a commercial enterprise, and it
> is in their best interested not to bend over backwards to work with a
> free competing product.
>
> The power I felt FPC has had was it's compatibility with Delphi. FPC
> maintained compatibility with the languages and even with the class
> library (SysUtils.pas, Classes.pas).
>
> I understand it's difficult to maintain this parity between FPC and
> Delphi, especially when Delphi does things which seem wrong (such as
> they way they implemented operator overloading), but IMO keeping that
> parity goes is more important than ego (if that is where the problem
> really lays).

Ego is not the problem. Time is, as Jonas pointed out.

My observations were purely from a more philosophical point of view;
In general we try to be Delphi compatible as much as time and
backward compatibility permits.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Marco van de Voort
In reply to this post by Anthony Walter-3
In our previous episode, Anthony Walter said:

> To Marco:
>
> Thanks for that link. I will read that rocument and try to get started
> with the developer repository and build environment this week. If I
> have and questions (which google and my own experimentation can't
> answer), where would be the best place to submit them?

The fpc-devel group and/or irc.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
In reply to this post by Jonas Maebe-2
On Mon, Nov 16, 2009 at 9:51 AM, Jonas Maebe <[hidden email]> wrote:
> I was merely answering your question why we do it differently than Delphi,
> even though Delphi is generally the de facto standard. I was trying to
> explain that we did not do it differently simply because our way was the
> right one and Delphi's way the wrong one, or out of spite or so. But it
> appears that you interpreted my answer in exactly the opposite sense (that
> we won't change it out of spite).

Yup. Got that. It's just that I've heard it a few times before and was
a bit confounded by the rational. No

> The main problem with changing it now would obviously be that it would break
> backwards compatibility with existing code. It could still be done in Delphi
> mode onlu, of course, but changing the behaviour of a calling convention
> (which is normally an ABI issue) based on a language syntax mode feels...
> not right.

I don't believe this fix would cause any problems with existing code.
The fix has been when using cdecl to declare const structures as
pointers to structures. That is to say:

function nanosleep(RequestedTime: PTimeSpec; Remaining: PTimeSpec):
Integer; cdecl;

Which would operate just the same.

Thank you all for your courtesy. I understand the issue better now.

I'll look into how to help out with the compiler development soon and
hopefully help improve FPC.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Anthony Walter-3
In reply to this post by Marco van de Voort
On Mon, Nov 16, 2009 at 10:19 AM, Marco van de Voort <[hidden email]> wrote:
> The fpc-devel group and/or irc.

On freenode I've been to #fpc a few times over the years. My handle is sysRPL.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: const records passed incorrectly

Jonas Maebe-2
In reply to this post by Marco van de Voort

On 16 Nov 2009, at 16:19, Marco van de Voort wrote:

> The fpc-devel group and/or irc.

The fpc-devel mailing list is best, I think, if only because the  
answers will be indexed by Google.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12