No, I'm not assuming this. There is a wine test that proves this. In
fact it regressed, so it was already correct before. I only fixed it
back to what it was. So all is good :)
Am 11.10.2014 18:43, schrieb Alex Ionescu:
Would be great to have JIRA issues associated to such
fixes as well as
a test proving the change is correct. For example, are you merely
assuming that you should return "STATUS_NO_MEMORY", or do you know for
a fact that STATUS_CONFLICTING_ADDRESSES is the wrong code here?
Best regards,
Alex Ionescu
On Wed, Oct 8, 2014 at 12:38 AM, <tkreuzer(a)svn.reactos.org
<mailto:tkreuzer@svn.reactos.org>> wrote:
Author: tkreuzer
Date: Wed Oct 8 07:38:56 2014
New Revision: 64595
URL:
http://svn.reactos.org/svn/reactos?rev=64595&view=rev
Log:
[NTOSKRNL]
Fix a status code
Modified:
trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
Modified: trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c…
==============================================================================
--- trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1]
(original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/vadnode.c [iso-8859-1] Wed
Oct 8 07:38:56 2014
@@ -261,7 +261,7 @@
{
DPRINT1("Not enough free space to insert this VAD
node!\n");
KeReleaseGuardedMutex(&CurrentProcess->AddressCreationLock);
- return STATUS_CONFLICTING_ADDRESSES;
+ return STATUS_NO_MEMORY;
}
ASSERT(StartingAddress != 0);
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev