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
