On 10/10/2016 01:28 PM, Wilco Dijkstra wrote:
> Martin Liška <mli...@suse.cz> wrote:
>> On 10/07/2016 01:21 PM, Wilco Dijkstra wrote:
>>
>>> I believe target_char_cast is incorrect if the host/target chars are not
>>> identical
>>> (depending on how constant strings are created there may be signed/unsigned
>>> mismatches too). I recently added target_char_cst_p to gimple-fold.c to
>>> avoid
>>> char representation mismatches, so it would be better to use that instead.
>>
>> Thank you for the predicate, I'm going to use it.
>>
>> I have one additional question whether also c_getstr should be guarded
>> with a similar guard? Or is it always safe to grab a char* by
>> TREE_STRING_POINTER
>> and use it by a host string functions (strcmp, ...)?
>
> Yes I guess that one is incorrect too. I can't find the internal
> implementation of tree strings,
> but it may well be that GCC just doesn't support any mismatches in
> host/target character
> size. In any case an explicit check won't do any harm as it isn't possible to
> use host string
> functions if there is a mismatch in character size.
I will dig in this situation. I'll build a cross-compiler which will have a
different character size.
>
> Another thing, what happens with:
>
> memchr ("abc", 225, 1000000000);
>
> It seems your new code will call memchr with the given size (and potentially
> crash) rather
> than report the obvious bug and set a consistent return value that doesn't
> rely on reading
> random memory on the host.
I asked Jakub about that on IRC already:
<marxin> Hi. Just thinking whether we should fold a case like __builtin_memchr
("a", 'x', 2), which is ubsan?
<jakub> marxin: what do you mean by that? That is NULL, without undefined
behavior
<marxin> jakub: sry, s/2/3
<jakub> marxin: don't fold that in that case
<marxin> jakub: good, I thought that
It's an opportunity for a warning and as I talked to Martin Sebor, he's aware
of this as an improvement
of his sprintf warnings he's currently working on.
Martin
>
> Wilco
>
>
>
