From: Josh Triplett <josh@joshtriplett.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: sparse@chrisli.org, linux-sparse@vger.kernel.org, will.deacon@arm.com
Subject: Re: [PATCH v2] sparse: treat function pointers as pointers to const data
Date: Sun, 7 Sep 2014 10:14:44 -0700 [thread overview]
Message-ID: <20140907171442.GA24467@thin> (raw)
In-Reply-To: <1410093413-3075-1-git-send-email-ard.biesheuvel@linaro.org>
On Sun, Sep 07, 2014 at 02:36:53PM +0200, Ard Biesheuvel wrote:
> This code snippet:
>
> static void bar(void const *arg)
> {
> int (*foo)(void) = arg;
> }
>
> produces the following warning:
>
> test.c:4:28: warning: incorrect type in initializer (different modifiers)
> test.c:4:28: expected int ( *foo )( ... )
> test.c:4:28: got void const *arg
>
> which is caused by the fact that the function pointer 'foo' is not annotated
> as being a pointer to const data. However, dereferencing a function pointer
> does not produce an lvalue, so a function pointer points to const data by
> definition, and we should treat it accordingly.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
As a data point: gcc does not warn about this case either, whereas it
does warn about "int *foo = arg". So, this seems fine to me.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> OK, so while my v1 did solve the example case, it turns out universally treating
> function pointers as pointers to const data produces so much fallout that it
> does more harm than good.
Can you elaborate on the fallout, and ideally provide that rationale in
the commit message?
- Josh Triplett
next prev parent reply other threads:[~2014-09-07 17:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-07 12:36 [PATCH v2] sparse: treat function pointers as pointers to const data Ard Biesheuvel
2014-09-07 17:14 ` Josh Triplett [this message]
2014-09-07 17:29 ` Ard Biesheuvel
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=20140907171442.GA24467@thin \
--to=josh@joshtriplett.org \
--cc=ard.biesheuvel@linaro.org \
--cc=linux-sparse@vger.kernel.org \
--cc=sparse@chrisli.org \
--cc=will.deacon@arm.com \
/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