https://bugs.winehq.org/show_bug.cgi?id=53172
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |fgouget@codeweavers.com
--- Comment #1 from François Gouget fgouget@codeweavers.com --- Windows's behavior RegEnumValueA() is broken in all cases where the name buffer is too small, but particularly so in double-byte and UTF-8 locales.
The test is configured to enumerate a single value:
Test: REG_SZ "foobar"
With: data_count = 20 memset(data, 'x', sizeof(data)) RegEnumValueA(...too small name buffer..., data, &data_count)
We randomly get one of the results below: * data_count=7 This is strlen("foobar")+1 which makes sense data[data_count] = 0 Modifying the buffer makes no sense in the first place. But should it be modified, then it should do data[data_count-1] = 0. Maybe this is a REG_SZ vs. REG_MULTI_SZ issue.
* 7 < data_count < 20 and data[data_count] = 0 The required buffer size is 7, there is no reason to claim more is needed. The returned values don't even seem to be random; it's mostly 8-11 and 13. There is still the data[data_count] vs. data[data_count-1] issue.
* data_count >= 20 and data is unmodified This seems to be specific to the UTF-8 cases (w10pro64_en_AE_u8 and w10pro64_hi_u8). Specifically the only value seen in this case is data_count = 21. Even if the initial data_count value is changed to 16. So why 21??? And fortunately RegEnumValueA() did not try to set data[data_count] = 0 (would be a buffer overflow). This is what's causing the failures for two reasons: - We memset(data, 'x', sizeof(data)) which means it's not \0-terminated. So strspn( data, "x" ) may return anything depending on what comes after the buffer. At least there's only a 1/256 chance of it being wrong. - data[data_count] is also outside the buffer and this time it has a 255/256 chance of being wrong (though in practice it's not random and may be more likely to be 0).