public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "Smith,
	Stan" <stan.smith-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Sasha Khapyorsky <sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org>,
	ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [OPENSM] cast to remove warnings about signed vs. unsigned comparisons
Date: Thu, 1 Oct 2009 12:27:34 -0600	[thread overview]
Message-ID: <20091001182734.GI19540@obsidianresearch.com> (raw)
In-Reply-To: <5700CAE1904A41378DAE71D5F81B9C55-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>

On Thu, Oct 01, 2009 at 10:10:13AM -0700, Sean Hefty wrote:
> >I've always felt the warning on implicit cast from larger to smaller
> >type to be somewhat useless - that is an unavoidable operation when
> >working with networking. Adding casts does nothing to actually improve
> >the code, and trying to change to smaller types results in worse code
> >gen and no improvement in function.
> 
> An explicit cast lets someone reading the code know that the
> original programmer was aware that data could be loss, or that data
> loss wouldn't occur because of the range of the data.  IMO, adding
> explicit casts to the code is better than having an equally number
> of implicit casts.

So for every cast your patches add you generate a rigorous proof that
the surrounding usage of those variables is correct and meets the
constraint? :)

All you really get is an annotation that there is a cast here. You
don't know what the type of operand is, you don't know if it is
an important cast, you don't know the type of the assignment
target. The explicit cast actually creats more questions, like, is
this truncating by design or because something got flubbed?

But the reader already knows that there is an implicit cast there -
this is C, all assignments can perform an implicit cast. A C
programmer must be aware of this and must know the types of all the
variables to correctly understand the code.

The biggest problem is that the cast is only correct if the types
never change. If someone changes the type then every instance of every
cast must be tracked down and fixed too. This is a huge maintenance
burden that implict casting avoids.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-10-01 18:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <839303D0FDC14F77AE516FDC9CF8B6A7@amr.corp.intel.com>
     [not found] ` <20091001155613.GN17846@me>
2009-10-01 16:14   ` [OPENSM] cast to remove warnings about signed vs. unsigned comparisons Smith, Stan
     [not found]     ` <3F6F638B8D880340AB536D29CD4C1E1912C86E862B-osO9UTpF0USkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2009-10-01 16:27       ` Jason Gunthorpe
     [not found]         ` <20091001162715.GC22310-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2009-10-01 17:02           ` Sasha Khapyorsky
2009-10-01 17:10           ` Sean Hefty
     [not found]             ` <5700CAE1904A41378DAE71D5F81B9C55-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2009-10-01 18:27               ` Jason Gunthorpe [this message]
     [not found]                 ` <20091001182734.GI19540-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2009-10-01 18:43                   ` Sean Hefty
2009-10-01 17:41           ` Smith, Stan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091001182734.GI19540@obsidianresearch.com \
    --to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org \
    --cc=sashak-smomgflXvOZWk0Htik3J/w@public.gmane.org \
    --cc=sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=stan.smith-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox