From patchwork Fri Jun 27 17:16:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christopher Li X-Patchwork-Id: 4436671 Return-Path: X-Original-To: patchwork-linux-sparse@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 7F1719F2C8 for ; Fri, 27 Jun 2014 17:16:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A63D2203AD for ; Fri, 27 Jun 2014 17:16:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 98C0820270 for ; Fri, 27 Jun 2014 17:16:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751425AbaF0RQY (ORCPT ); Fri, 27 Jun 2014 13:16:24 -0400 Received: from mail-qg0-f46.google.com ([209.85.192.46]:58940 "EHLO mail-qg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751419AbaF0RQX (ORCPT ); Fri, 27 Jun 2014 13:16:23 -0400 Received: by mail-qg0-f46.google.com with SMTP id q107so4571532qgd.19 for ; Fri, 27 Jun 2014 10:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=61PKPkXnXVMMbUdKcD/FUJPQT7b/i6JLB6W9HOUAz2I=; b=cxiZRifjvyJJQKrjrinQerFaJedvhyOZUcU5v7Ig304FgNGM2PIZ0YdvNXg0kyG7ZR h0b2piSoYoNMjX1Ss7HbKmwZXwMeDCteUmaWInwgnEqfW62DqsBDjS+VcVV9pBbGJQQy AMKDpHUNJbXtlB127XQLDW7CCyWvLun4NNxr2DFSnQv5+wd1UiInJo6k0w+QqhFZAoTO 0vlYVaHBpzm8MoMhpXq8UxHfdtjWBhvDUqH9qXYJm4CTHBGyNjcLglzvOObQULLFMZOp xGTec/tl/XYgWCBuw4r2+IeK/EyJ4K+ve4I4mOuQaqmhwd1mQDLcUXopWW3c2jhuauiJ IaOw== MIME-Version: 1.0 X-Received: by 10.140.29.139 with SMTP id b11mr33115928qgb.44.1403889383190; Fri, 27 Jun 2014 10:16:23 -0700 (PDT) Received: by 10.140.102.8 with HTTP; Fri, 27 Jun 2014 10:16:23 -0700 (PDT) In-Reply-To: <20140627111900.GA19158@phil.dovecot.net> References: <1402315082-14102-1-git-send-email-phil@dovecot.fi> <1402386847-23477-1-git-send-email-phil@dovecot.fi> <20140627111900.GA19158@phil.dovecot.net> Date: Fri, 27 Jun 2014 10:16:23 -0700 X-Google-Sender-Auth: UASjx5RZ6KYyuxz76xSoSoos4S8 Message-ID: Subject: Re: [PATCHv2 0/3] catch non-sign-extended '~' brainos From: Christopher Li To: Phil Carmody Cc: Josh Triplett , Linux-Sparse Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Jun 27, 2014 at 4:19 AM, Phil Carmody wrote: > > Any comments on these? > Sorry I am falling behind the patches, again. I have been thinking about your patch for a few days. It is very common to implicit cast up, do some binary operation then cast back down. e.g. static unsigned long long val; static unsigned int ok10 = val | ~1u; static unsigned char a; static unsigned char ok11 = val | ~a; Your patch will give false positive warning about those. Do you known how many new warning does it give on the new kernel build after apply your patch? I suspect there is a lot of false positive. I want to do that but haven't get around to it yet. Hint hint... To reduce the false positive, we can check the zero extended bits survived to the final expression. e.g. the finial expression did down cast again and lost those bits. I also want an option to turn this warning off because the possible false positive. Also, if you only care about warning against up cast "~" of unsigned type, you can do the checking at cast_to(). It will be simpler. I have a sort patch like this, given that I did not check for the "unsigned int" type, nor do I check for binary op. You can still get the idea. In this way, you don't need to predict the up cast will happen or not. You can call when the implicit up cast actually happens. It does not solve the problem of checking down cast after up cast of finial expression though. Chris old->unop = cast_to(old->unop, type); --- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/evaluate.c b/evaluate.c index 7ce8c55..47e660e 100644 --- a/evaluate.c +++ b/evaluate.c @@ -294,8 +294,11 @@ static struct expression * cast_to(struct expression *old, struct symbol *type) */ switch (old->type) { case EXPR_PREOP: - if (old->ctype->bit_size < type->bit_size) + if (old->ctype->bit_size < type->bit_size) { + if (old->op == '~') + warning(old->pos, "dubious zero-extended '~'"); break; + } if (old->op == '~') { old->ctype = type;