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@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?rev=64595&r1=64594&r2=64595&view=diff
==============================================================================
--- 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@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev