This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/3] Fold __builtin_memchr (version 2)
On 10/10/2016 01:28 PM, Wilco Dijkstra wrote:
> Martin Liška <mliska@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
>
>
>