[PATCH 2/3] Fold __builtin_memchr (version 2)

Martin Liška mliska@suse.cz
Mon Oct 10 11:37:00 GMT 2016

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.


> Wilco

More information about the Gcc-patches mailing list