任务单 #44471

Wrong prototype of IsProcessInJob

开放日期: 2022-04-26 21:42 最后更新: 2022-05-23 21:08

报告人:
属主:
(无)
类型:
状态:
开启
组件:
里程碑:
(无)
优先:
5 - Medium
严重性:
5 - Medium
处理结果:
文件:
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Details

The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:

WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);

I think it should instead be this:

WINBASEAPI BOOL WINAPI IsProcessInJob (HANDLE, HANDLE, PBOOL);

I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.

任务单历史 (3/7 Histories)

2022-04-26 21:42 Updated by: eliz
  • New Ticket "Wrong prototype of IsProcessInJob" created
2022-05-04 05:48 Updated by: keith
评论

Reply To eliz

The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:
        WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);

I think it should instead be this:
        WINBASEAPI BOOL WINAPI IsProcessInJob (HANDLE, HANDLE, PBOOL);

I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.

I suspect that you are correct. Microsoft's (woeful) documentation neither supports, nor refutes your conjecture, but if your proposed prototype adjustment both resolves the linking issue, and exhibits correct run-time behaviour, that would seem to be sufficient justification for making the change.

2022-05-04 06:35 Updated by: keith
评论

In winbase.h I also see one other declaration, which appears to be similarly malformed:

$ hg grep WINBASEAPI | grep -v WINAPI
... snip ...
w32api/include/winbase.h:WINBASEAPI HLOCAL LocalDiscard (HLOCAL);
w32api/include/winbase.h:WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);

Although the declaration of LocalDiscard here has every appearance of being similarly malformed, the issue is different. Microsoft's documentation, in this case, suggests that LocalDiscard should be defined as a macro, (but offers no hint as to how it should be defined). Indeed, there does not appear to be any symbol, exported from kernel32.dll, which could possibly resolve any reference to LocalDiscard.

I have no idea how to fix this.

2022-05-04 14:42 Updated by: eliz
评论

Reply To keith

Reply To eliz

The prototype of IsProcessInJob, as it is provided by winbase.h in the w32api MinGW package seems to be incorrect:
        WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL);

I think it should instead be this:
        WINBASEAPI BOOL WINAPI IsProcessInJob (HANDLE, HANDLE, PBOOL);

I found this because the existing prototype causes link error, since the linker is looking for the wrong symbol in the libraries.

I suspect that you are correct. Microsoft's (woeful) documentation neither supports, nor refutes your conjecture, but if your proposed prototype adjustment both resolves the linking issue, and exhibits correct run-time behaviour, that would seem to be sufficient justification for making the change.

Yes, the change I propose definitely solved linking errors in a program where I needed this function.

2022-05-04 14:42 Updated by: eliz
评论

Reply To keith

In winbase.h I also see one other declaration, which appears to be similarly malformed: {{{ $ hg grep WINBASEAPI | grep -v WINAPI ... snip ... w32api/include/winbase.h:WINBASEAPI HLOCAL LocalDiscard (HLOCAL); w32api/include/winbase.h:WINBASEAPI BOOL IsProcessInJob (HANDLE, HANDLE, PBOOL); }}} Although the declaration of LocalDiscard here has every appearance of being similarly malformed, the issue is different. Microsoft's documentation, in this case, suggests that LocalDiscard should be defined as a macro, (but offers no hint as to how it should be defined). Indeed, there does not appear to be any symbol, exported from kernel32.dll, which could possibly resolve any reference to LocalDiscard. I have no idea how to fix this.

Are we allowed to take ideas from what MinGW64 did in this case?

2022-05-23 08:10 Updated by: keith
评论

Reply To eliz

Are we allowed to take ideas from what MinGW64 did in this case?

Presumably you mean by reading their header files? Sorry, but I consider that to be a poisoned chalice, so I'd have to say "no". I'd be more inclined to accept ideas gleaned from the (doxygen format) ReactOS reference documentation — at least that offers something akin to a "chinese wall", and doesn't involve directly reading header files, which we suspect may have been plagiarized from Microsoft's copyrighted sources.

2022-05-23 21:08 Updated by: eliz
评论

Reply To keith

Reply To eliz

Are we allowed to take ideas from what MinGW64 did in this case?

Presumably you mean by reading their header files? Sorry, but I consider that to be a poisoned chalice, so I'd have to say "no". I'd be more inclined to accept ideas gleaned from the (doxygen format) ReactOS reference documentation — at least that offers something akin to a "chinese wall", and doesn't involve directly reading header files, which we suspect may have been plagiarized from Microsoft's copyrighted sources.

I don't think it matters where we take the idea for the implementation, ReactOS is as good a source as any.

(My alternative suggestion would be that I describe in prose what MinGW64 did, and you use that description to write the code. AFAIU, this works around the copyright restriction, since ideas cannot be copyrighted. But it's an academic issue now.)

Attachment File List

No attachments

编辑

Please login to add comment to this ticket » 登录名