Hi.

I understood why programs calling DosSetFilePtr caused SYS3171 due to Tomas.

Thanks. And I also know that my patch is not fundamental solution.

I know, name of function exported or imported must be real name, i.e. _DosSetFilePtr

not _DOSCALLS$$_DOSSETFILEPTR$LONGINT$LONGINT.

So I propose that if only 'external' directive is appeared, disable

encoding in FPC style, else enable encoding in FPC style. In other words,

the expansion of function name is up to 'external' not to 'cdecl' directive.

'cdecl' is just 'calling convention' not rule of making funciton name.

In conclusion, if there is 'export' in exporting librares, there is

'external' in importing libraries.

Wrong ?

Finally, I want to access fpc-devel archives, but welcoming me is

'page not found' message.

For better FPC !!!

from KO Myung-Hun...

you wrote

the expansion of function name is up to 'external' not to 'cdecl' directive. 'cdecl' is just 'calling convention' not rule of making funciton name.

Hmm, but C has also rules how the names are mangled, so cdecl should also change the name.

Date sent: Sat, 28 Oct 2000 15:56:12 +0200
To:
From: Florian Klaempfl
Subject: Re: [fpc-devel]cdecl directive & fpc-devel archives...
Send reply to:

On one hand you're making it difficult to use the C calling convention for some internal routine. OK, I don't know a situation when this might be useful at the moment, so fixing the compiler to issue at least some warning message might be enough regarding this. On the other hand the current implementation complicates (at least - I don't really know whether it's even possible currently) creating a routine with Pascal calling convention but a non-mangled name as well.
Anyway, what about my question regarding the implementation in other compilers (I mean mostly TPW and Delphi here)?

Tomas

Anyway, what about my question regarding the implementation in other compilers (I mean mostly TPW and Delphi here)?

I think this is less relevant. Both TPW and Delphi had the luxury that the C compilers they linked to were made by the same company, so they could adapt both sides to keep things interchangable.

We have to keep the linking possibility to gcc at any cost, since without it, the value of having Linux and FreeBSD platforms decimates. But on the other hand we also have to keep linkability to several Win32 C compilers and Delphi because of the DLL's.

Personally I think that if we should make fundamental changes to the external linking stuff, it would have to be a fundamental reconsideration of declaring calling conventions and external.

A good example would be to consider the TopSpeed way. The TopSpeed range of compilers (which I used before FPC) allowed full configuration of callingconventions for each individual procedure with directives like this: (only schematic, don't have TS here atm)

{#pragma cconv=>pascal,reg=>ax,dx,cx,freg=st(0),st(1)}

Which means something like:
- Pascal order of pushing parameters, opposed to C
- Register parameters, first param in ax, second in dx, third in cx (parameters bigger than wordsize are put on the stack), floating point values on the copro stack, but no more than two values in 0 and 1).
Reg=>' ' meant no reg parameters IIRC.

If we then also allow to redefine external, cdecl and their mangling with such directives, we could get much more control over external linking, and support a lot more compilers in a systematic way, without too much different modi, directives and all together if necessary. (like linking to cygwin static libs, while in a different unit linking to Delphi DLLs etc)

It probably is something for the new cg (since it would be wise to do it together with the reg parameters possibility to avoid double work).

In that case for all processors a list with the prefered order for registerparameters should be used, so that the definition would be more or less processor independant.

Some much used settings (like gcc and the diffent conventions of delphi) could be predefined, and also different compiler modes could have different defaults.