On Monday, March 28 2016, 21:05 UTC+11, Nikolay Sivov wrote:
On 28.03.2016 12:52, Hugh McMaster wrote:
Signed-off-by: Hugh McMaster
programs/regedit/listview.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/programs/regedit/listview.c b/programs/regedit/listview.c index c0119ff..5b1bd80 100644 --- a/programs/regedit/listview.c +++ b/programs/regedit/listview.c @@ -174,6 +174,19 @@ static void AddEntryToList(HWND hwndLV, LPWSTR Name, DWORD dwValType, ListView_SetItemTextW(hwndLV, index, 2, buf); } break;
case REG_DWORD_BIG_ENDIAN: {DWORD i, value = 0;BYTE *data = ValBuf;WCHAR buf[64];WCHAR fmt[] = {'0','x','%','0','8','x',' ','(','%','u',')',0};for (i = 0; i < dwCount; i++) {value <<= 8;value |= data[i];}sprintfW(buf, fmt, value, value);ListView_SetItemTextW(hwndLV, index, 2, buf);}break; case REG_BINARY: { unsigned int i; LPBYTE pData = ValBuf;
dwCount is always 1 in this case,
dwCount is 4 for REG_DWORD and REG_DWORD_BIG_ENDIAN.
so it could be simplified to the point of swapping 'value' and falling through to REG_DWORD case. I didn't check tests, but you sure you need to modify what RegQueryValueExW() returns?
On Windows, regedit displays the REG_DWORD type in little endian order and the REG_DWORD_BIG_ENDIAN type in big endian order.
But both "reg query" and RegQueryValueEx() return any type of DWORD in little endian order.
While it is true that there is common code in REG_DWORD and the BIG_ENDIAN case, I'm not sure there is a clean way to handle the endianness without checking for and handling the value type a second time.