Dodgy header translation into Delphi?

From: Martin Harvey (Demon account) (martin_at_nospam_pergolesi.demon.co.uk)
Date: 10/31/04 

Date: Sat, 30 Oct 2004 22:58:13 GMT

Hmmm ... I've come across a bit of an oddity in the Delphi translation
of the Win32 headers....

MSDN says:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setwaitabletimer.asp

BOOL SetWaitableTimer(
  HANDLE hTimer,
  const LARGE_INTEGER* pDueTime,
  LONG lPeriod,
  PTIMERAPCROUTINE pfnCompletionRoutine,
  LPVOID lpArgToCompletionRoutine,
  BOOL fResume
);

However, in Delphi 4 at least, this ends up translating into:

function SetWaitableTimer(hTimer: THandle; const lpDueTime:
TLargeInteger;
  lPeriod: Longint; pfnCompletionRoutine: TFNTimerAPCRoutine;
  lpArgToCompletionRoutine: Pointer; fResume: BOOL): BOOL; stdcall;

Which looks really a bit suspect. Why do I say this? Well, pDueTime
should definitely be a pointer. However, I was then able to write:

WaitableTimer := CreateWaitableTimer(nil, false, nil);
Assert(WaitableTimer <> 0);
SetWaitableTimer(WaitableTimer, 0, TIMER_PERIOD, nil, nil, false);

The problem is that I can write a constant zero into the second
parameter.

Now, there's likely to be plenty of const confusion here - but the
second parameter is meant to be a (variable in callee) pointer to a
constant large integer. (The MSDN docs don't quite seem clear to me as
to whether that pointer can be NULL).

However, Delphi has translated all this subtlety into "const". Well,
are constants passed by pointer or not? "var" parameters certainly
are, but I'm concerned that const parameters of 4 bytes or less may
not - because based on the percieved intent of the C declaration, I
would not expect to be able to pass a constant large integer value
into the function.

Of course, if it was really smart, the Delphi compiler might simply
allocate a zeroed 64 bit quantity in the data segment, and then pass a
pointer to that to the procedure ... but I'm not convinced it's going
to do that ... ;-)

Unfortunately, I won't be able to test this for a day or so until I've
written enough supporting code...

MH.

Relevant Pages

  • Re: Whats the big deal with cross-platform?
    ... that I must often look to see if a pointer was translated as var ... structures etc. that confuse the hell out of a Delphi programmer. ... I think the translation should not divert from the original. ... I/we would not even discuss the issue of header ...
    (borland.public.delphi.non-technical)
  • Re: Whats the big deal with cross-platform?
    ... This avoids compatibility problems. ... --for newer Delphi or OS versions? ... A translation is only useful if it conveys the gist of the issue. ... the reasons I wrote my pointer article). ...
    (borland.public.delphi.non-technical)
  • Re: Whats the big deal with cross-platform?
    ... for those who are in a position to correct the translation --if ... The documentation of the API ... that I must often look to see if a pointer was translated as var ... example in the Platform SDK help to Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Is this legal ?
    ... >> to be followed again if the compiler can't guarantee that nothing that ... >address of an object into a pointer to const type version, ... to change it (by casting away const from a pointer to it, ...
    (comp.lang.c)
  • Re: Why is the kfree() argument const?
    ... is there any reason why kfreetakes a const pointer just to degrade it ... In the particular case of kfree(), the pointer argument *should* be const, ... If a struct has a constant pointer to it, ...
    (Linux-Kernel)