[PATCH] shlwapi: Avoid ARRAY_SIZE-like macros

[Ken Thomases]

> On Sep 20, 2018, at 10:00 PM, Mathew Hodson <mathew.hodson at gmail.com> wrote:
> 
> On Fri, 14 Sep 2018 at 18:12, Michael Stefaniuc <mstefani at winehq.org> wrote:
>> 
>> Signed-off-by: Michael Stefaniuc <mstefani at winehq.org>
>> ---
>> dlls/shlwapi/path.c | 10 ++++------
>> dlls/shlwapi/reg.c  |  7 +++----
>> dlls/shlwapi/url.c  |  2 +-
>> 3 files changed, 8 insertions(+), 11 deletions(-)
>> 
>> diff --git a/dlls/shlwapi/path.c b/dlls/shlwapi/path.c
>> index ae05381b66..e24835f238 100644
>> --- a/dlls/shlwapi/path.c
>> +++ b/dlls/shlwapi/path.c
>> @@ -4217,8 +4217,6 @@ HRESULT WINAPI SHGetWebFolderFilePathW(LPCWSTR lpszFile, LPWSTR lpszPath, DWORD
>> {
>>   static const WCHAR szWeb[] = {'\\','W','e','b','\\','\0'};
>>   static const WCHAR szWebMui[] = {'m','u','i','\\','%','0','4','x','\\','\0'};
>> -#define szWebLen (sizeof(szWeb)/sizeof(WCHAR))
>> -#define szWebMuiLen ((sizeof(szWebMui)+1)/sizeof(WCHAR))
> 
> Doesn't this change the calculation? I don't see the +1 retained in
> any of the updated uses of szWebMui.

No, because of integer division.  sizeof(WCHAR) is 2, so the added 1 doesn't actually affect the result of the original calculation.

Now, the original may have been intended to add 1 to the overall length, but that's a different issue.  Doesn't seem necessary, though.  szWebMui is already null terminated and the format sequence "%04x" is the same size as the formatted value will be.

Regards,
Ken