Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2023-11

About the var param in CreateConsoleScreenBuffer

4 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Martin Frb
Fpc defines
function CreateConsoleScreenBuffer(dwDesiredAccess:DWORD;
dwShareMode:DWORD; var lpSecurityAttributes:SECURITY_ATTRIBUTES;
dwFlags:DWORD; lpScreenBufferData:LPVOID):HANDLE; external 'kernel32'
name 'CreateConsoleScreenBuffer';

`lpSecurityAttributes` is a `var` param in the above. But https://learn.microsoft.com/en-us/windows/console/createconsolescreenbuffer states that the param is optional and can be null/nil. var param don't accept nil. So this should be a pointer instead.

Yet,  this was reported in
https://gitlab.com/freepascal.org/fpc/source/-/issues/5836 That issue got closed "*Fixed in version:* 1.9.9"
Only "git blame" shows no change to that line ever. (Well afaik some commits are not in git, so could be).

So the question is: Was it fixed and broken again? Was it fixed but not committed?
Or does the cryptic comment

Show quoted text 5 lines
Pascal CONST can be both by reference (thus consuming a *) or by value. This is the only safe way.

mean its a "wont fix" ?
And if that is the case, then what does this comment mean?

Reply by email

Marco van de Voort
to Martin Frb

Op 9-11-2023 om 13:59 schreef Martin Frb via fpc-devel:

Show quoted text 10 lines
Fpc defines function CreateConsoleScreenBuffer(dwDesiredAccess:DWORD; dwShareMode:DWORD; var lpSecurityAttributes:SECURITY_ATTRIBUTES; dwFlags:DWORD; lpScreenBufferData:LPVOID):HANDLE; external 'kernel32' name 'CreateConsoleScreenBuffer'; `lpSecurityAttributes` is a `var` param in the above. But https://learn.microsoft.com/en-us/windows/console/createconsolescreenbuffer states that the param is optional and can be null/nil. var param don't accept nil. So this should be a pointer instead.

Seems so yes.

Show quoted text 9 lines
Yet,  this was reported in https://gitlab.com/freepascal.org/fpc/source/-/issues/5836 That issue got closed "*Fixed in version:* 1.9.9" Only "git blame" shows no change to that line ever. (Well afaik some commits are not in git, so could be). So the question is: Was it fixed and broken again? Was it fixed but not committed?

No idea. Annotating revisions in the bugtracker mostly only happened with SVN, and afaik this is still CVS era  (?)

Anyway, standard procedure in such cases is to move the pascallized declaration to redef.inc and have a pointer value in the original place. Which I just commited to GIT.

Show quoted text 9 lines
Or does the cryptic comment > > Pascal CONST can be both by reference (thus consuming a *) or by value. > > This is the only safe way. > mean its a "wont fix" ? And if that is the case, then what does this comment mean?

I think that hints on C const and pascal const not necessarily matching. (i.e. pre CONSTREF), and using VAR instead. Possibly read over the NIL passing bit.

Reply by email

Marco van de Voort
to Martin Frb

Op 9-11-2023 om 20:43 schreef Martin Frb via fpc-devel:

Show quoted text 7 lines
On 09/11/2023 14:19, Marco van de Voort via fpc-devel wrote: > > Anyway, standard procedure in such cases is to move the pascallized > declaration to redef.inc and have a pointer value in the original > place. Which I just commited to GIT. Thanks. Merge-able?

I usually review my own commits every couple of months, or when a branch of a release is imminent.

Reply by email