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@xxxxxxxxxx>
---
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.
Instead, this v2 only addresses function pointer initializers and assignments.
--
Ard.
evaluate.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/evaluate.c b/evaluate.c
index 66556150ddac..a5a830978bda 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -1359,6 +1359,15 @@ static int compatible_assignment_types(struct expression *expr, struct symbol *t
typediff = "different address spaces";
goto Err;
}
+ /*
+ * If this is a function pointer assignment, it is
+ * actually fine to assign a pointer to const data to
+ * it, as a function pointer points to const data
+ * implicitly, i.e., dereferencing it does not produce
+ * an lvalue.
+ */
+ if (b1->type == SYM_FN)
+ mod1 |= MOD_CONST;
if (mod2 & ~mod1) {
typediff = "different modifiers";
goto Err;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
