On 08/17/2018 12:44 PM, Bernd Edlinger wrote: > On 08/17/18 20:23, Martin Sebor wrote: >> On 08/17/2018 06:14 AM, Joseph Myers wrote: >>> On Fri, 17 Aug 2018, Jeff Law wrote: >>> >>>> On 08/16/2018 05:01 PM, Joseph Myers wrote: >>>>> On Thu, 16 Aug 2018, Jeff Law wrote: >>>>> >>>>>> restores previous behavior. The sprintf bits want to count element >>>>>> sized chunks, which for wchars is 4 bytes (that count will then be >>>>> >>>>>> /* Compute the range the argument's length can be in. */ >>>>>> - fmtresult slen = get_string_length (arg); >>>>>> + int count_by = dir.specifier == 'S' || dir.modifier == FMT_LEN_l ? 4 >>>>>> : 1; >>>>> >>>>> I don't see how a hardcoded 4 is correct here. Surely you need to example >>>>> wchar_type_node to determine its actual size for this target. >>>> We did kick this around a little. IIRC Martin didn't think that it was >>>> worth handling the 2 byte wchar case. >> >> Sorry, I think we may have miscommunicated -- I didn't think it >> was useful to pass a size of the character type to the function. >> I agree that passing in a hardcoded constant doesn't seem right >> (even if GCC's wchar_t were always 4 bytes wide). >> >> I'm still not sure I see the benefit of passing in the expected >> element size given that the patch causes c_strlen() fail when >> the actual element size doesn't match ELTSIZE. If the caller >> asks for the number of bytes in a const wchar_t array it should >> get back the number bytes. (I could see it fail if the caller >> asked for the number of words in a char array whose size was >> not evenly divisible by wordsize.) >> > > I think in this case c_strlen should use the type which the %S format > uses at runtime, otherwise it will not have anything to do with > the reality. That's a different issue than what Martin is talking about, but is the same as what Joseph is asking us to fix.
This is well outside my area of expertise, but I believe Windows has 16 bit wchar_t, so these tests probably aren't working correctly on cygwin/mingw. Jeff
