This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add a character size parameter to c_strlen/get_range_strlen

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]