On Mon, 22 Mar 2004, Boaz Harrosh wrote:
module.c GetProcAdress will not "Fly" on a NULL module. It will Just return with Error set to ERROR_PROC_NOT_FOUND (127). Actually, I did a little check, On ms-windows any garbage HMODULE will Just Return an error. Is there a ValidPointer/magic_number check we can do before we "fly" here.
A small test in dlls/kernel/tests/*.c for this would be perfect. In general, it's better to submit such a test, rather than write a throw-away one on your box only.
Dimitrie O. Paun wrote:
A small test in dlls/kernel/tests/*.c for this would be perfect. In general, it's better to submit such a test, rather than write a throw-away one on your box only.
You were, like always, right. I did a test and found that Wine is OK just like in windows. Probably in the version I was working on, when this fix was done, There was something Screwy with the exceptions and the kernel code did not catch them. But now it does and returns a proper error. I will submit a new patch with Just the winpos.c code.
Free Life Boaz
? dlls/kernel/tests/loadlib.c Index: dlls/kernel/tests/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- dlls/kernel/tests/Makefile.in 9 Feb 2004 20:58:16 -0000 1.14 +++ dlls/kernel/tests/Makefile.in 23 Mar 2004 07:10:11 -0000 @@ -26,7 +26,8 @@ process.c \ profile.c \ thread.c \ - virtual.c + virtual.c \ + loadlib.c --- /dev/null 1970-01-01 02:00:00.000000000 +0200 +++ ./loadlib.c 2004-03-23 09:09:20.000000000 +0200 @@ -0,0 +1,41 @@ +/* + * Unit test suite for LoadLibrary / GetProcAdress functions + * + * Copyright 2003 wine project + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdarg.h> +#include <stdlib.h> + +#include "windows.h" +#include "wine/test.h" + +START_TEST(loadlib) +{ + void* pProc = GetProcAddress( NULL ,"NotARealFunc" ) ; + int err = GetLastError() ; + ok(pProc==NULL, "GetProcAdress copes with NULL error is %d\n",err); + printf("GetProcAdress copes with NULL error is %d\n",err); + + todo_wine + { + void* pProc = GetProcAddress((void*) 0x117 ,"NotARealFunc" ) ; + int err = GetLastError() ; + ok(pProc==NULL, "GetProcAdress copes with BAD HModule error is %d\n",err); + printf( "GetProcAdress copes with BAD HModule error is %d\n",err); + } +}
On March 23, 2004 2:46 am, Boaz Harrosh wrote:
Probably in the version I was working on, when this fix was done, There was something Screwy with the exceptions and the kernel code did not catch them. But now it does and returns a proper error.
But if that's the case, why is the test marked as todo_wine:
+ todo_wine + { + void* pProc = GetProcAddress((void*) 0x117 ,"NotARealFunc" ) ; + int err = GetLastError() ; + ok(pProc==NULL, "GetProcAdress copes with BAD HModule error is %d\n",err); + printf( "GetProcAdress copes with BAD HModule error is %d\n",err); + }
Dimitrie O. Paun wrote:
On March 23, 2004 2:46 am, Boaz Harrosh wrote:
Probably in the version I was working on, when this fix was done, There was something Screwy with the exceptions and the kernel code did not catch them. But now it does and returns a proper error.
But if that's the case, why is the test marked as todo_wine:
todo_wine- {
void* pProc = GetProcAddress((void*) 0x117 ,"NotARealFunc" ) ;int err = GetLastError() ;ok(pProc==NULL, "GetProcAdress copes with BAD HModule error is %d\n",err);printf( "GetProcAdress copes with BAD HModule error is %d\n",err);}
I don't think there is a point in submitting this test. I Just sent it because it was there. and thought may be you wanted to have a look. The test does pass with or with out the todo.
If on the subject. I have a question: What to do with testes that throw an exception ("fly") but don't do so on ms-windows? leaving that in, would stop the test application, and all tests after that would not preform. I did have a couple of cases like that.
Boaz Harrosh boaz@hishome.net writes:
What to do with testes that throw an exception ("fly") but don't do so on ms-windows? leaving that in, would stop the test application, and all tests after that would not preform. I did have a couple of cases like that.
It would be possible to enforce timeout to make the run time bounded. Not implemented yet, but on the TODO list. Have you got a better idea?
Ferenc Wagner wrote:
It would be possible to enforce timeout to make the run time bounded. Not implemented yet, but on the TODO list. Have you got a better idea?
On ms-windows with msvc++ I would have Just put an exception catchall handler and would catch 99.99% of possible exceptions. I think dlls/kernel has such code. Maybe someone knows how to write a macro for wine-tests that would let you do something like:
try_test{ gpf_test() ; } catch_test(){ ok( 0 ,"gpf_test has failed") ; }
this would certainly let test continue, No ?
<side note> exceptions is on my TODO list. I'm looking for a way to tie the g++ and gcc exceptions to the Wine's structured exceptions, like on windows. For winelib apps. Maybe the only way is to back port MinGW for elf. </side note>
Free Life Boaz
Boaz Harrosh boaz@hishome.net writes:
Ferenc Wagner wrote:
It would be possible to enforce timeout to make the run time bounded. Not implemented yet, but on the TODO list. Have you got a better idea?
On ms-windows with msvc++ I would have Just put an exception catchall handler and would catch 99.99% of possible exceptions.
I didn't make myself clear. The tests are separate processes, they can only pause winetest by popping up a dialog box and waiting for the user to close it. I tried
SetErrorMode (SEM_FAILCRITICALERRORS);
but this didn't help. If this worked we would need timeout for looping tests only. Unfortunately I'm not a Windows guru to solve this without much experimentation (or at all).
On March 24, 2004 1:33 am, Boaz Harrosh wrote:
I don't think there is a point in submitting this test. I Just sent it because it was there. and thought may be you wanted to have a look. The test does pass with or with out the todo.
First off, I think there is a very good point submitting the test. Why not? I can't easily think of a case where a test should not be submitted. It formalizes behaviour for future Wine hacker.
Second, I thought that a test should fail if it runs OK but is bracketed by a todo_wine, no?
-
Boaz Harrosh -
Dimitrie O. Paun -
Dimitrie O. Paun -
Ferenc Wagner