Christopher Li <sparse@xxxxxxxxxxx> writes:
> On Thu, Nov 24, 2016 at 2:33 AM, Nicolai Stange <nicstange@xxxxxxxxx> wrote:
>>
>> While doing this, I recognized that sparse's current constant expression
>> tagging scheme was quite limited and I had to touch everything related
>> to it anyway. So I asked on this list on whether it would be a good
>> thing to let sparse be more strict than gcc in this regard and the
>> feedback was that it certainly would (at user option).
>
> Good. Thanks for reminding of that. So ideally this is under a more
> strict options.
As it stands, [09/21] ("evaluate: check static storage duration objects'
intializers' constness"), introduces the opt-in -Wconstexpr-not-const.
This affects only initializers for objects of static storage duration.
So, there is currently no way to opt out from the stricter integer
constant expression checks etc. introduced with this series.
I ran sparse with this series applied on the kernel back then and if I
remember correctly, there was no spectacular difference though.
If these stricter semantics nevertheless became a problem, this would be
easily "fixable" by further relaxing them at user option, I think.
> No, please don't send the series again. I have a script system to
> process the patches now. So no patch will be missed from now on.
Alright. May I further ask whether you've got all these precious
Reviewed-by tags from Luc carried over? He did a great amount of review
work on this series and it would be quite sad if these got lost.
I still have them, so just tell me if you need a list. If not:
nevermind.
>>> Integer constant expression can be tested as:
>>>
>>> !(flags & ( Addr | Float) ) && flag
>>>
>>> Arithmetic constant expression can be tested as:
>>>
>>> !(flags & Addr) ) && flag
>>>
>>> Do you see any problem with this internal representation?
>>
>> (int)0.0 is an integer constant expression.
>>
>> In your scheme, it would have "composite op" and "float" set?
>> The integer constant expression test you proposed above would
>> fail in this case.
>>
>
> (int) 0.0 will express as "Composite op" and "Int const" set.
> Cast is a special operation it will strip the "float" and convert it
> to "int". After all that is what cast does.
Ah ok, i mistook you in the semantics of the composite op flag.
> It will not change your patch behavior and warning etc, it is just
> a internal representation difference. How the constant expression
> bits are store and interpreted.
Yes, yes got that. Don't get me wrong, I'm not defending my particular
choice of flags. If yours leads to cleaner/less code, I will be very
happy.
That being said, here's the next "corner case":
0 + 'a'
Which flags would be set for this binary expression? All of "composite
op", "integer const", "char const"?
That would work with your test for integer constant expressions.
I think, it wouldn't be enough to just set "composite op" flag w/o
anything else since the above integer constant expression needs to get
distinguished from
0 + 0.0
which is an arithmetic constant expression only. Thus, considering your
tests for integer vs. arithmetic constant expressions, this would need
to have at least its "float constant" flag set?
Thank you,
Nicolai
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
