Linux SPARSE checker discussions
 help / color / mirror / Atom feed
From: Al Viro <viro@ftp.linux.org.uk>
To: linux-sparse@vger.kernel.org
Subject: pointer arithmetics and casts
Date: Fri, 25 May 2007 22:23:00 +0100	[thread overview]
Message-ID: <20070525212300.GL4095@ftp.linux.org.uk> (raw)

	Looking through the old problems: pointer addition is not done
right.  What happens is simple - p + i turns into

	BINOP[+]
		<tree for p>
		BINOP[*]
			<tree for i>
			VAL[sizeof(*p)]

and we end up multiplying i and sizeof(*p) in wrong type.  On 64bit host
we _must_ expand i to 64 bits before we multiply; otherwise we get
wraparounds.

The question is, what do we do about that?  The obvious way would be
to do cast_to(), i.e. turn the above into

	BINOP[+]
		<tree for p>
		BINOP[*]
			IMPLICIEDT_CAST[ptrdiff_t]
				<tree for i>
			VAL[sizeof(*p)]

But that means a fsckload of extra nodes allocated on pretty much any
program - use of arrays is not rare and indices tend to be int, so we
hit an extra allocated node on each such place.

Another possible solution is to add a primitive for combined conversion
and multiplication - basically, convert the first argument to the type of
the second one and multiply.  We would actually need it only for ptrdiff_t;
sizeof(*p) is going to fit into the range anyway (it has to - the difference
between (char *)(p+1) and (char *)p must fit into it, or we couldn't do any
arithmetics on that pointer type at all; as soon as product overflows
ptrdiff_t we are free to do whatever the hell we like, since that's an
undefined behaviour and "multiply as ptrdiff_t values" gives an reasonable
result even in such cases).

That would cut down on extra nodes, but we pay for that by getting an
extra node type for linearizer, etc. to deal with.  Not sure how nasty
that's going to be...

Comments?

             reply	other threads:[~2007-05-25 21:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-25 21:23 Al Viro [this message]
2007-05-25 22:00 ` pointer arithmetics and casts Al Viro
2007-05-26 15:45   ` Al Viro
2007-05-26  1:14 ` Morten Welinder
2007-05-26  3:32   ` Derek M Jones
2007-05-26  4:16     ` Al Viro
2007-05-26  3:43   ` Al Viro
2007-05-26  3:44 ` Neil Booth
2007-05-26  4:22   ` Al Viro
2007-05-26  4:37     ` Neil Booth

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=20070525212300.GL4095@ftp.linux.org.uk \
    --to=viro@ftp.linux.org.uk \
    --cc=linux-sparse@vger.kernel.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