On Fri, Sep 18, 2015 at 08:16:52PM +0200, Manuel López-Ibáñez wrote:
> On 18/09/15 18:45, Martin Sebor wrote:
> >but it makes me wonder how common this pattern is in portable
> >code and whether adding workarounds for it is the right solution
> >(or if it might prompt people to disable the warning, which would
> >be a shame).
>
> Perhaps if we are going to warn, we could look for sizeof() and virtual
> locations in the operands, and skip the warning. It would be nice to find a
> heuristic that allows warning in most cases but skip those that appear often
> in common code.
Yeah, but as I mentioned in the previous mail, we don't have the ability to
do that. For sizeof perhaps we could use SIZEOF_EXPR, but since integer
constants don't have a location we can't use from_macro_expansion_at for them.
I think the warning works right in most cases already, just in some weird
cases it fires. Perhaps that's acceptable, but I know people aren't keen on
adding kludges to their code to suppress warnings...
So like I said, maybe -Wextra for now.
> Another alternative is to have a more heuristic version of operand_equal(),
> if two operands are equal because of "compilation-dependent" code (macro
> expansion, sizeof, etc), then they are not considered equal. that is
> operand_equal_2(sizeof(long), sizeof(long)) returns true, but
> operand_equal_2(8, sizeof(long)) returns false.
>
> I have no idea whether it is possible to implement operand_equal_2 in a sane
> way.
I'm not sanguine about that at all :/.
Marek
