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, <tkreu...@svn.reactos.org > <mailto:tkreu...@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
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
