Hi/2 all.

I found bugs in doscalls.pas.

First, prototype of DosDevIOCtl function is incorrect. DataLen argument need not 'var'. So prototype of DosDevIOCtl must be not

function DosDevIOCtl(Handle,Category,Func:longint;var Params;
                     ParamLen:longint;var ParamSize:longint;
                     var Data;var DataLen:longint;var DataSize:
                     longint):longint; cdecl;

but

function DosDevIOCtl(Handle,Category,Func:longint;var Params;
                     ParamLen:longint;var ParamSize:longint;
                     var Data;DataLen:longint;var DataSize:
                     longint):longint; cdecl;

Second is DosSetFilePtr function. Original functions from DOSCALL.DLL

must be declared 'cdecl' model. But helper(?) function is not. In

addtion, in case of DosSetFilePtr, If DosSetFilePtr helper function is

declared 'cdecl', then programs calling DosSetFilePtr encounter SYS3171

error.

So, 'cdecl' of helper of DosSetFilePtr is removed.

By the way, why programs calling DosSetFilePtr encounter SYS3171 ?

In reamrk of doscalls.pas, Daniel said that helper is regardless to

'cdecl'.

What's the problem ?

For better FPC !!!

from KO Myung-Hun...

Date sent: Tue, 24 Oct 2000 22:11:00 +0900
From: KO Myung-Hun
To: FPC mail
Subject: [fpc-devel]Bugs in DosCalls.pas
Send reply to:

Hi again,

I found bugs in doscalls.pas. First, prototype of DosDevIOCtl function is incorrect. DataLen argument need not 'var'. So prototype of DosDevIOCtl must be not

thanks, I'll have a look at this.

cdecl is needed for the imported call, whereas it shouldn't matter for the helper (although the current situation, where one helper uses C calling convention and the other not, is quite strange).

By the way, why programs calling DosSetFilePtr encounter SYS3171 ?

I guess there might be some problem in the compiler, since it should handle both calling conventions for internal functions (and our helper is nothing but an internal function). Could you send a short compilable example that shows the problem, please?

Tomas

Date sent: Tue, 24 Oct 2000 22:11:00 +0900
From: KO Myung-Hun
To: FPC mail
Subject: [fpc-devel]Bugs in DosCalls.pas
Send reply to:

Hi,

function DosDevIOCtl(Handle,Category,Func:longint;var Params; ParamLen:longint;var ParamSize:longint; var Data;DataLen:longint;var DataSize: longint):longint; cdecl;

you're absolutely right here, I'm changing it now.

This is somewhat more complicated as I found now. Your solution (removing cdecl for the helper) solves the immediate problem, so I'm applying it now as well. However, the reason of the problem is somewhat wider (I'm sending a copy of this message to the core developers' list as well so that people not reading this list regularly can join the discussion).
What's the matter - cdecl causes not only a different calling convention to be used, but prevents the normal identifier name "encoding" as well. For example the identifier of the DosSetFilePtr function is internally encoded into
_DOSCALLS$$_DOSSETFILEPTR$LONGINT$LONGINT, whereas with the cdecl modifier, just _DosSetFilePtr is used. However, this is the same as the name of the original (overloaded) function imported from the DLL. This behaviour is wrong in my opinion. First, there's no warning about the double declaration. However, I don't see a reason for using non-encoded identifiers at all in functions/procedures those are not imported and not declared as exported either. I think we should introduce some other modifier for cases when the programmer wants to allow this behaviour (non-encoded names) explicitly. I don't know how Delphi solves this problem (if it supports something like cdecl at all), but at least Virtual Pascal does exactly this (well, it's less convenient there, since one has to disable the encoding even for imported functions manually, but that's another story).
Your opinions?

Have a nice day

Tomas Hajny, on Internet
in urgent cases