This fixes a few warnings gcc gives me when compiling. If this is an okay approach, there's a lot more patches I have for all the other tests. This warning appears a lot.
Signed-off-by: Fabian Maurer dark.shadow4@web.de --- dlls/adsldp/tests/ldap.c | 10 +++++----- dlls/adsldp/tests/sysinfo.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/dlls/adsldp/tests/ldap.c b/dlls/adsldp/tests/ldap.c index fe9801a3972..161fc5d0bbc 100644 --- a/dlls/adsldp/tests/ldap.c +++ b/dlls/adsldp/tests/ldap.c @@ -190,7 +190,7 @@ static void test_ParseDisplayName(void)
count = 0xdeadbeef; hr = MkParseDisplayName(bc, test[i].path, &count, &mk); -todo_wine_if(i == 0 || i == 1 || i == 11 || i == 12) + todo_wine_if(i == 0 || i == 1 || i == 11 || i == 12) ok(hr == test[i].hr, "%d: got %#x, expected %#x\n", i, hr, test[i].hr); if (hr == S_OK) { @@ -394,7 +394,7 @@ static void test_DirectorySearch(void) ok(hr == E_ADS_BAD_PARAMETER, "got %#x\n", hr);
hr = IDirectorySearch_GetPreviousRow(ds, sh); -todo_wine + todo_wine ok(hr == E_ADS_BAD_PARAMETER, "got %#x\n", hr);
while (IDirectorySearch_GetNextRow(ds, sh) != S_ADS_NOMORE_ROWS) @@ -430,9 +430,9 @@ todo_wine
name = NULL; hr = IDirectorySearch_GetNextColumnName(ds, sh, &name); -todo_wine + todo_wine ok(hr == S_OK || broken(hr == S_ADS_NOMORE_COLUMNS) /* XP */, "got %#x\n", hr); -todo_wine + todo_wine ok((name && !wcscmp(name, L"ADsPath")) || broken(!name) /* XP */, "got %s\n", wine_dbgstr_w(name)); FreeADsMem(name);
@@ -488,7 +488,7 @@ static void test_DirectoryObject(void) ok(hr == S_OK, "got %#x\n", hr);
hr = IDirectoryObject_QueryInterface(dirobj, &IID_IADsOpenDSObject, (void **)&unk); -todo_wine + todo_wine ok(hr == E_NOINTERFACE, "got %#x\n", hr); if (hr == S_OK) IUnknown_Release(unk); hr = IDirectoryObject_QueryInterface(dirobj, &IID_IDispatch, (void **)&unk); diff --git a/dlls/adsldp/tests/sysinfo.c b/dlls/adsldp/tests/sysinfo.c index c7495dcb88b..4e7b0b405a9 100644 --- a/dlls/adsldp/tests/sysinfo.c +++ b/dlls/adsldp/tests/sysinfo.c @@ -123,7 +123,7 @@ static void test_UserName(void) ok(hr == S_OK, "got %#x\n", hr);
hr = IADsADSystemInfo_get_UserName(sysinfo, &bstr); -todo_wine + todo_wine ok(hr == S_OK || hr == HRESULT_FROM_WIN32(ERROR_NONE_MAPPED), "got %#x\n", hr); if (hr == S_OK) { @@ -164,7 +164,7 @@ static void test_sysinfo(void) SysFreeString(bstr);
hr = IADsADSystemInfo_get_UserName(sysinfo, &bstr); -todo_wine + todo_wine ok(hr == S_OK || hr == HRESULT_FROM_WIN32(ERROR_NONE_MAPPED), "got %#x\n", hr); if (hr != S_OK) goto done; SysFreeString(bstr); -- 2.34.1
Fabian Maurer dark.shadow4@web.de wrote:
-todo_wine_if(i == 0 || i == 1 || i == 11 || i == 12)
todo_wine_if(i == 0 || i == 1 || i == 11 || i == 12)
They are intentionally formatted like this. A correct way to fix it is to remove the 'todo_wine'. Here, and in other places.
Hello Dmitry,
I know they're intentionally formatted like that. But it causes a lot of compile warning, or errors when using -Werror. I don't think it should be that using todo_wine causes compile warnings. Sure, in a perfect world we'd never need todo_wine, but we're not in a perfect world and I want to avoid compile warnings.
Alternative would be to manually add curly braces, this would make the compiler happy as well. But fixing the indentation seems more logical to me.
Regards, Fabian Maurer
Fabian Maurer dark.shadow4@web.de wrote:
I know they're intentionally formatted like that. But it causes a lot of compile warning, or errors when using -Werror. I don't think it should be that using todo_wine causes compile warnings. Sure, in a perfect world we'd never need todo_wine, but we're not in a perfect world and I want to avoid compile warnings.
Probably the compiler shouldn't emit this kind of warnings, and disabling the warning is another option, perhaps just in a local build if this kind of warnings bothers too much.
Alternative would be to manually add curly braces, this would make the compiler happy as well. But fixing the indentation seems more logical to me.
More logical seems fixing the place a todo_wine was added for.
I know they're intentionally formatted like that. But it causes a lot of compile warning, or errors when using -Werror. I don't think it should be that using todo_wine causes compile warnings. Sure, in a perfect world we'd never need todo_wine, but we're not in a perfect world and I want to avoid compile warnings.
Probably the compiler shouldn't emit this kind of warnings, and disabling the warning is another option, perhaps just in a local build if this kind of warnings bothers too much.
The warning seems fine to me. The compiler sees a for-loop without braces and code with the same indentation afterwards. That is usually misleading, it's just that Wine uses the for-loop in a creative way.
Sure, I could disable the warnings. Doesn't seem like a good solution for me. Do we want to add -Wno-misleading-indentation to configure? It is (or will be) needed to compile in maintainer/Werror mode.
Alternative would be to manually add curly braces, this would make the compiler happy as well. But fixing the indentation seems more logical to me.
More logical seems fixing the place a todo_wine was added for.
You can't expect me to fix all those todos just because I don't want warnings.
Regards, Fabian Maurer
Dmitry Timoshkov dmitry@baikal.ru writes:
Fabian Maurer dark.shadow4@web.de wrote:
I know they're intentionally formatted like that. But it causes a lot of compile warning, or errors when using -Werror. I don't think it should be that using todo_wine causes compile warnings. Sure, in a perfect world we'd never need todo_wine, but we're not in a perfect world and I want to avoid compile warnings.
Probably the compiler shouldn't emit this kind of warnings, and disabling the warning is another option, perhaps just in a local build if this kind of warnings bothers too much.
The warning did catch a few real issues, so I don't think we want to disable it. Yes, it will cause some code churn to reindent the todos, but it's only in tests so I think it's acceptable.
Alternative would be to manually add curly braces, this would make the compiler happy as well. But fixing the indentation seems more logical to me.
More logical seems fixing the place a todo_wine was added for.
Fixing all the todos is not a realistic option.
-
Alexandre Julliard -
Dmitry Timoshkov -
Fabian Maurer