On 08/22/2018 05:22 PM, Bernd Edlinger wrote:
> On 08/23/18 00:50, Jeff Law wrote:
>> On 08/22/2018 02:14 AM, Richard Biener wrote:
>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>
>>>> On 08/22/18 09:26, Richard Biener wrote:
>>>>> On Wed, 22 Aug 2018, Bernd Edlinger wrote:
>>>>>
>>>>>> On 08/21/18 10:59, Richard Biener wrote:
>>>>>>> On Tue, 21 Aug 2018, Bernd Edlinger wrote:
>>>>>>>
>>>>>>>> gcc -S -O2 -Wall -Wformat-overflow -ftrack-macro-expansion=0
>>>>>>>> -fshort-wchar builtin-sprintf-warn-20.c
>>>>>>>> builtin-sprintf-warn-20.c: In function 'test':
>>>>>>>> builtin-sprintf-warn-20.c:19:39: warning: hex escape sequence out of
>>>>>>>> range
>>>>>>>> 19 | ? (char*)L"\x4142\x4344" : (char*)L"\x41424344\x45464748";
>>>>>>>> | ^~~~~~~~~~~~~~~~~~~~~~~
>>>>>>>>
>>>>>>>> Hmm, this test might create some noise on short-wchar targets.
>>>>>>>>
>>>>>>>> I would prefer a warning here, about the wrong type of the parameter.
>>>>>>>> The buffer overflow is only a secondary thing.
>>>>>>>>
>>>>>>>> For constant objects like those, the GIMPLE type is still guaranteed
>>>>>>>> to be reliable,
>>>>>>>> right?
>>>>>>>
>>>>>>> TREE_TYPE of tcc_declaration and tcc_constant trees should more-or-less
>>>>>>> (minus qualifications not affecting semantics) be those set by
>>>>>>> frontends.
>>>>>>>
>>>>>>
>>>>>> and in this case:
>>>>>>
>>>>>> const union
>>>>>> { struct {
>>>>>> wchar_t x[4];
>>>>>> };
>>>>>> struct {
>>>>>> char z[8];
>>>>>> };
>>>>>> } u = {{L"123"}};
>>>>>>
>>>>>> int test()
>>>>>> {
>>>>>> return __builtin_strlen(u.z);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> string_constant works out the initializer for u.x
>>>>>> which has a different type than u.z
>>>>>
>>>>> Yes. That's because it uses ctor-for-folding and friends. It's
>>>>> a question of the desired semantics of string_constant whether
>>>>> it should better return NULL_TREE in this case or whether the
>>>>> caller has to deal with type mismatches.
>>>>>
>>>>
>>>> Yes, absolutely.
>>>>
>>>> c_getstr needs to bail out if the string is not zero-terminated
>>>> within the limits given by the decl, or the string_cst-type or whatever
>>>> may help.
>>>>
>>>> Furthermore I also consider it possible that the byteoffset
>>>> is not a multiple of eltsize. So fail in that case as well.
>>>>
>>>>
>>>> I am currently boot-strapping a patch for this (pr87053):
>>>> $ cat u.c
>>>> const union
>>>> { struct {
>>>> char x[4];
>>>> char y[4];
>>>> };
>>>> struct {
>>>> char z[8];
>>>> };
>>>> } u = {{"1234", "567"}};
>>>>
>>>> int test()
>>>> {
>>>> return __builtin_strlen(u.z);
>>>> }
>>>>
>>>> gets folded to 4.
>>>>
>>>> ... but unfortunately it will depend on my pr86714 fix which fixes
>>>> the mem_size parameter returned from string_constant.
>>>>
>>>> Frankly, in the moment I feel like I fell in a deep deep hole. :-O
>>>
>>> /me too with > 100 mails in this and related threads unread ;)
>>>
>>> I thought Jeff applied the mem_size parameter thing but maybe it
>>> was something else. *fetches coffee* Ah, Jeff is still "working"
>>> on it.
>> The patch that was applied adds a parameter to c_strlen to indicate how
>> it should count (ie, bytes, 16bit wchars or 32bit wchars).
>>
>> There was one hunk that was dependent upon an earlier, more
>> controversial, patch from Bernd which is still under discussion. That
>> hunk was twiddled to preserve the overall goal of Bernd's patch which
>> added the how to count parameter without being dependent upon the older,
>> more controversial patch.
>>
>
> Which patch do you mean?
This one:
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Thu Aug 16 22:38:04 2018 +0000
* builtins.c (c_strlen): Add new parameter eltsize. Use it
for determining how to count the elements.
* builtins.h (c_strlen): Adjust prototype.
* expr.c (string_constant): Add new parameter mem_size.
Set *mem_size appropriately.
* expr.h (string_constant): Adjust protoype.
* gimple-fold.c (get_range_strlen): Add new parameter eltsize.
* gimple-fold.h (get_range_strlen): Adjust prototype.
* gimple-ssa-sprintf.c (get_string_length): Add new
parameter eltsize.
(format_string): Call get_string_length with eltsize.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@263607
138bc75d-0d04-0410-961f-82ee72b054a4
jeff