Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Regarding this commit
Previous implementation was :
So this was always returning
varkind
whenentry.desc
was defined. The function name is consistent : we try to retrieveinvoke_type
fromdesc
and returndefault_invoke_type
otherwise.Regarding new implementation :
The logic is totally different, we check
varkind
to possibly amendinvoke_type
, but we never returnvarkind
.In the related issue of this pull request, we found out that when setting
AdminQueueInfo
member of anMSMQ.MSMQMessage
, we call_GetDescInvokeType
with an entry verifyingentry.desc[4] = 8
and aninvoke_type = INVOKE_PROPERTYPUT
.We should get a
INVOKE_PROPERTYPUTREF (8)
, corresponding toentry.desc[4]
but new function returnsINVOKE_PROPERTYPUT
and makesinvoke
crash.The pull request is proposing a mix between two implementations, but I'm still really confused, especially with
entry.desc[4]
which apparently should correspond tovarkind
. Looking to documentationvarkind
values can only be 0,1,2,3.So what is really
entry.desc[4]
?