[PATCH] Add a character size parameter to c_strlen/get_range_strlen
Bernd Edlinger
bernd.edlinger@hotmail.de
Sun Aug 26 09:10:00 GMT 2018
On 08/26/18 07:47, Jeff Law wrote:
> On 08/21/2018 11:49 AM, Martin Sebor wrote:
>> On 08/21/2018 09:44 AM, Joseph Myers wrote:
>>> On Tue, 21 Aug 2018, Martin Sebor wrote:
>>>
>>>> Sure, but the only valid argument to %ls is wchar_t*. Passing
>>>> it something else is undefined.
>>>
>>> Well, (wchar_t *)"something\0\0\0\0" would be OK given
>>> -fno-strict-aliasing and if you know the alignment is OK. Do we have
>>> that
>>> information about the type cast to, as opposed to the type of the string
>>> constant, at this point?
>>
>> In the simple cases like the one above the cast is gone. Only
>> in some more involved cases is the type of the argument preserved.
>> I responded to Jeff with one such example here:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01296.html
>>
>> If supporting (wchar_t *)"...\0\0\0\0" with %ls is viewed as
>> important (despite it being undefined) then the function does
>> need an ELTSIZE argument so it knows what to count. In that
>> event, in order to detect the problem cases we have been
>> discussing (missing nuls and mismatched argument types),
>> the function it must not fail when ELTSIZE is not equal
>> to the size of actual array element. Instead, it needs to
>> return the element type to the caller which then needs to
>> do the validation and issue a diagnostic.
> So I think that argues that the sanity check should be removed or
> otherwise neutered when if/when we attack the argument type mismatching
> problems.
>
Yes, I think folding strlen(L"") to 0 should still be avoided,
but a warning would be good at the same time.
Bernd.
More information about the Gcc-patches
mailing list