Hello,

I've hit another segfault, this time it was code calling WinApi function GetTempFileName(). Resolving the call explicitly to Windows.GetTempFileName() works. It appears that problem is in cross-platform analog of GetTempFileName() that is contained in SysUtils unit.
Looking at the RTL source, I could not figure out how it's expected to work. In 'rtl/objpas/osutilsh.inc' there is a declaration:

function GetTempFileName(Dir,Prefix: PChar; uUnique: DWORD; TempFileName: PChar):DWORD; (note that it's not compatible with WinApi because 'stdcall' is missing!)

The corresponding implementation in 'rtl/objpas/osutil.inc' is compiled conditionally:

{$if not(defined(win32)) and not(defined(win64))}
function GetTempFileName(...
...
{$endif}

Naturally, under Windows the function is not needed because it's contained in WinApi. But then function declaration in interface must also be wrapped into conditional section, otherwise how such code gets compiled?

Op Fri, 1 Sep 2006, schreef Sergei Gorelkin:

There exists a wrapper in rtl/win/sysutils.pp, which is necessary because otherwise a "uses sysutils" would not be enough to use this function. Both the Windows specific and the platform independend one do not use syscall and are therefore compatible with each other.

Daniël

Friday, September 01, 2006, 11:48:17 AM, Daniël wrote:

DM> Op Fri, 1 Sep 2006, schreef Sergei Gorelkin:

DM> There exists a wrapper in rtl/win/sysutils.pp, which is necessary because DM> otherwise a "uses sysutils" would not be enough to use this function. Both DM> the Windows specific and the platform independend one do not use syscall DM> and are therefore compatible with each other.

DM> Daniël

Ok, now I understand where does the implementation come from. Then the bug is caused by missing 'stdcall' modifier in SysGetTempFileName() declaration (rtl/win/sysutils.pp, line 79). Could you please add it?

Op Fri, 1 Sep 2006, schreef Sergei Gorelkin:

Done, r4527 in trunk.

Daniël