• last updated 15 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Why not just keep checking NewMdList != NULL? Or even ARGUMENT_PRESENT(NewMdList)

Why not just keep checking NewMdList != NULL? Or even ARGUMENT_PRESENT(NewMdList)

Don't like 'break'? https://code.reactos.org/static/olpro3/2static/images/wiki/icons/emoticons/wink.gif

Don't like 'break'?

Descriptor makes more sense here than NextEntry

Descriptor makes more sense here than NextEntry

This is an __out. Also why not SAL2?

This is an __out. Also why not SAL2?

BasePage = BasePage would be more obvious

BasePage = BasePage would be more obvious

Why is there no truncate/coalesce/savepointer in this case?

Why is there no truncate/coalesce/savepointer in this case?

You mean NextDescriptor in these two lines

You mean NextDescriptor in these two lines

Same as in the Truncate function: deref'ing pointers that are not known-good

Same as in the Truncate function: deref'ing pointers that are not known-good

magic

magic

I understand the "never coalesce" flag since the do-coalesce flag can come from the MemoryDescriptor. But why is there a "never truncate" flag if all it does is remove the truncate flag from the sa...

I understand the "never coalesce" flag since the do-coalesce flag can come from the MemoryDescriptor. But why is there a "never truncate" flag if all it does is remove the truncate flag from the same variable?

... this however, I'd rather not see. You could be dereferencing based on the list head.

... this however, I'd rather not see. You could be dereferencing based on the list head.

Normally you shouldn't even use CONTAINING_RECORD unless the pointer in question is actually valid (i.e. NextEntry != MdList->First), but that's fine in practice if you don't reference it...

Normally you shouldn't even use CONTAINING_RECORD unless the pointer in question is actually valid (i.e. NextEntry != MdList->First), but that's fine in practice if you don't reference it...

Even if we assume the BaseAddress can never be the same, which I suppose is likely given they're memory descriptors: O0, O4, C2, L1, S3, A5 Becomes ['O0', 'C2', 'O4', 'L1', 'S3', 'A5'] Which is nei...

Even if we assume the BaseAddress can never be the same, which I suppose is likely given they're memory descriptors:
O0, O4, C2, L1, S3, A5
Becomes ['O0', 'C2', 'O4', 'L1', 'S3', 'A5']
Which is neither address ordering nor C<O<S<L<A

This ordering is strange. It's neither a "lower address first" nor a "higher precedence first" order, and gives a lot of emphasis to "order of insertion." Let's say I insert the following descripto...

This ordering is strange. It's neither a "lower address first" nor a "higher precedence first" order, and gives a lot of emphasis to "order of insertion."
Let's say I insert the following descriptors (in that order): Other0, Other2, Other1, Conventional0, Loader0, System1, Application0, Conventional1, System0, Application1, Loader1

That will give me a list like this:
Other0, Conventional0, Other1, Conventional1, Other2, Loader0, System0, System1, Application0, Application1, Loader1

Should the precedence only count if address is the same? That would give us: Conventional0, Other0, System0, Loader0, Application0, Conventional1, Other1, System1, Loader1, Application1, Other2
Or should the address only count if precedence is the same? Conventional0, Conventional1, Other0, Other1, Other2, System0, System1, Loader0, Loader1, Application0, Application1

Or is it really supposed to be like this?

Deriving i from Type1 and j from Type2 would be more logical

Deriving i from Type1 and j from Type2 would be more logical

This loop and the above do the same thing so they should look the same

This loop and the above do the same thing so they should look the same

Save a nesting level by making this if (Class2 != BlSystemClass) return TRUE; ?

Save a nesting level by making this if (Class2 != BlSystemClass) return TRUE; ?

Make the condition while (ThisEntry != FirstEntry) and move this block after the loop

Make the condition while (ThisEntry != FirstEntry) and move this block after the loop

These comparisons to ListEntry only make sense because it's the first member. So they should probably use a local PBL_MEMORY_DESCRIPTOR

These comparisons to ListEntry only make sense because it's the first member. So they should probably use a local PBL_MEMORY_DESCRIPTOR

Missing ~

Missing ~

Bootlib Mm
Bootlib Mm
That's not... why... don't do that...

That's not... why... don't do that...

Looks true. Investigation needed.

Looks true. Investigation needed.

I see a race condition here where CapturedObjectName's "not-NULL" state is different from what ObCreateObject sees. Don't know if that's dangerous yet, will have to look in more detail.

I see a race condition here where CapturedObjectName's "not-NULL" state is different from what ObCreateObject sees. Don't know if that's dangerous yet, will have to look in more detail.

I don't use the buffer per se (just the fact that it is NULL or not). The proper capture is done by ObCreateObject itself.

I don't use the buffer per se (just the fact that it is NULL or not). The proper capture is done by ObCreateObject itself.

Wouldn't it be easier to mark ClientMessage as volatile? (or are these the only 2 places where it's needed.)

Wouldn't it be easier to mark ClientMessage as volatile?
(or are these the only 2 places where it's needed.)

Shouldn't you also capture the Buffer?

Shouldn't you also capture the Buffer?

Oh correct!

Oh correct!

In general. But I guess we have "!gflag +soe" for that

In general. But I guess we have "!gflag +soe" for that

I guess removing it is fine

I guess removing it is fine