From: "Jan Pokorný" <pokorny_jan@seznam.cz>
To: Linux-Sparse <linux-sparse@vger.kernel.org>
Cc: Christopher Li <sparse@chrisli.org>
Subject: [RFC] evaluate: pointer arithmetics on plain void* (was: [PATCH] evaluate: reject post-ops on void*)
Date: Mon, 23 Jan 2012 11:32:33 +0100 [thread overview]
Message-ID: <4F1D3741.2030604@seznam.cz> (raw)
In-Reply-To: <4F1C9C49.2050707@seznam.cz>
Hm, I was talking about post-ops only, the example showed a failing pre-op
...both is a single case as evaluate_preop boils down to evaluate_postop.
I went through evaluate.c again and I think these cases should be somehow
unified (stating current state):
1. evaluate_postop:
a. function: error ("bad argument type for ++/--")
b. void*: nothing, but buggy evaluation (add/sub -1)
2. evaluate_ptr_add
a. function: warning ("arithmetics on pointers to functions")
b. void*: nothing, sizeof(void) implicitly considered as 1
3. evaluate_sizeof:
a. function: warning ("expression using sizeof on a function")
b. void: warning ("expression using sizeof(void)")
(c. bool: warning ("expression using sizeof bool"))
4. evaluate_ptrsizeof:
- ?
The original patch makes 1b. an equivalent to 1a. The alternative
is to handle 1b. in a similar way as 2b. Maybe both would deserve
a warning.
Still, there is at least one inconsistency: 1a. vs 2a. (error vs warning).
On 01/23/2012 12:31 AM, Jan Pokorný wrote:
> Following example haven't been linearized correctly:
>
> static void *inc_ptr(void *a) {
> return ++a;
> }
>
> test-linearize:
>
> <entry-point>
> add.32 %r2 <- %arg1, $-1
> ret.32 %r2
>
> Apparently, something went wrong with -1 value to be added to the original
> pointer. When void* substituted for int*, the result is as expected
> (considering 32b int):
>
> <entry-point>
> add.32 %r2 <- %arg1, $4
> ret.32 %r2
>
> The proposed patch turns post-ops on void* operand into an error
> (taking the same route as with function operand).
>
> When running check with C=2 on my old linux-3.0.6 configuration,
> this detected a few occurencies:
>
> drivers/scsi/scsi_proc.c:405:31: error: bad argument type for ++/--
> drivers/scsi/scsi_proc.c:413:23: error: bad argument type for ++/--
> net/bluetooth/hci_core.c:1545:29: error: bad argument type for ++/--
> net/bluetooth/l2cap_core.c:1825:37: error: bad argument type for ++/--
> net/bluetooth/bnep/core.c:239:13: error: bad argument type for ++/--
> lib/sort.c:25:27: error: bad argument type for ++/--
> lib/sort.c:26:27: error: bad argument type for ++/--
> lib/check_signature.c:21:24: error: bad argument type for ++/--
>
> All of them seems trivially fixable.
>
> Alternatively, I can turn it to emit an warning only (should be
> configurable/default?). To be noted that GCC will only emit an warning,
> and only if -pedantic or -Wpointer-arith specified, but I consider
> it rather a convenient exception.
>
> When this gets clear, I'll add also the respective test-case.
>
> Signed-off-by: Jan Pokorny <pokorny_jan@seznam.cz>
> ---
> evaluate.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/evaluate.c b/evaluate.c
> index bebe968..b6d706b 100644
> --- a/evaluate.c
> +++ b/evaluate.c
> @@ -1711,7 +1711,8 @@ static struct symbol *evaluate_postop(struct expression *expr)
> multiply = 1;
> } else if (class == TYPE_PTR) {
> struct symbol *target = examine_pointer_target(ctype);
> - if (!is_function(target))
> + /* beside function, reject also void* (due to sizeof(void)) */
> + if (target != &void_ctype && !is_function(target))
> multiply = bits_to_bytes(target->bit_size);
> }
>
--
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
next prev parent reply other threads:[~2012-01-23 10:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-22 23:31 [PATCH] evaluate: reject post-ops on void* Jan Pokorný
2012-01-23 10:32 ` Jan Pokorný [this message]
2012-01-23 16:17 ` [RFC] evaluate: pointer arithmetics on plain void* Jan Pokorný
2012-01-24 10:54 ` [RFC] evaluate: pointer arithmetics on plain void* (was: [PATCH] evaluate: reject post-ops on void*) Christopher Li
2012-01-27 11:42 ` [PATCH] evaluate: reject post-ops on void* Christopher Li
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=4F1D3741.2030604@seznam.cz \
--to=pokorny_jan@seznam.cz \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.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