Ticket #44471

Wrong prototype of IsProcessInJob

Date d'ouverture: 2022-04-26 21:42 Dernière mise à jour: 2022-05-04 14:42

Rapporteur:
Propriétaire:
(Aucun)
Type:
État:
Ouvert
Composant:
Jalon:
(Aucun)
Priorité:
5 - moyen
Sévérité:
5 - moyen
Résolution:
Aucun
Fichier:
Aucun
Vote
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)

Détails

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.

Ticket History (3/5 Histories)

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

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
Commentaire

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
Commentaire

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
Commentaire

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?

Attachment File List

No attachments

Modifier

Please login to add comment to this ticket » Connexion