チケット #44471

Wrong prototype of IsProcessInJob

登録: 2022-04-26 21:42 最終更新: 2022-05-23 21:08

報告者:
担当者:
(未割り当て)
チケットの種類:
状況:
オープン
コンポーネント:
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
なし
ファイル:
なし
投票
点数: 0
No votes
0.0% (0/0)
0.0% (0/0)

詳細

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.

チケットの履歴 (7 件中 3 件表示)

2022-04-26 21:42 更新者: eliz
  • 新しいチケット "Wrong prototype of IsProcessInJob" が作成されました
2022-05-04 05:48 更新者: 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 更新者: 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 更新者: 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 更新者: 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 更新者: 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 更新者: 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.)

添付ファイルリスト

添付ファイルはありません

編集

このチケットにコメントを追加するには、ログインが必要です » ログインする