Sorry for my late reply.
Manuel López-Ibáñez <lopeziba...@gmail.com> writes:
> This patch fixes almost all false positives in PR43772. The case not fixed is:
>
> intmax_t i = (whatever);
> if (INT_MAX < i && i <= LONG_MAX)
> print ("i is in 'long' but not 'int' ran")
>
> where we warn if INT_MAX = LONG_MAX < INTMAX_MAX.
FWIW, I'd be inclined to warn in that case, unless someone comes with a
reasonable scenario that argues for the usefulness of not warning here.
Maybe I am missing something.
> Perhaps with the macro location code, we could now tell that the
> constants INT_MAX and LONG_MAX come from different macro expansions in
> system headers, and avoid warning in this specific case, but that
> would be better done in a follow-up patch.
Hmmh.
> Dodji, is that possible?
> how could it be done?
It might be possible, even if I doubt if the value of doing that really
offsets the cost the perceived weirdness of the approach.
Assuming the token for resulting from INT_MAX and LONG_MAX haven't been
folded, you could get the line maps of their locations by using
linemap_lookup (line_table, location_of_token).
Then, make if linemap_macro_expansion_map_p is true on the the two line
maps, it means the tokens for INT_MAX and LONG_MAX come from macro
expansions. Then if the maps are different, it means the macro
expansions are different. To know if they (the macros) come from system
headers, you can use the predicate LINEMAP_SYSP on them.
But if INT_MAX/LONG_MAX are folded into a constant, then the information
about their macro-ness is lost, unfortunately.
--
Dodji
