Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer
Op 9-11-2023 om 20:43 schreef Martin Frb via fpc-devel: 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer
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? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer
Op 9-11-2023 om 13:59 schreef Martin Frb via fpc-devel: 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. 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] About the var param in CreateConsoleScreenBuffer
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 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?___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
