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

Reply via email to