Re: [PATCH 0/1] Constify struct address_space_operations for 2.6.32-git-053fe57acv2

From: Emese Revfy
Date: Wed Dec 16 2009 - 17:22:44 EST


Pavel Machek wrote:
> Hi!
>
>>> One const in structure declaration seems to be just enough, see:
>>>
>>> const struct a {
>>> void (* f)(void);
>>> void (* const g)(void);
>>> } s;
>>>
>>> void h(void)
>>> {
>>> struct a *p = &s;
>>> s.f = 0;
>>> s.g = 0;
>>> p->f = 0;
>>> p->g = 0;
>>> }
>>>
>>>
>>> delme.c: In function 'h':
>>> delme.c:8: warning: initialization discards qualifiers from pointer target type
>>> delme.c:9: error: assignment of read-only variable 's'
>>> delme.c:10: error: assignment of read-only variable 's'
>>> delme.c:12: error: assignment of read-only member 'g'
>>>
>>> You get clean-enough warnings.
>> Notice how you got an error for line 12 (p->g assignment) but no warning or error
>> at all for line 11 (p->f assignment). This example illustrates what I was explaining
>> so far:
>
> And notice how you get warning for line 8? That's what I'm talking
> about, and it should be enough to make the developer think about what
> he's doing.
> Pavel

You are talking about in-kernel ops structures whose constness will
prevent bad code from being written. On the other hand, I was talking
about new code yet-to-enter the kernel where the developer has no indication
that he should be using a const ops structure (other than perhaps checkpatch
except apparently things easily fall through the cracks, see my series for
file_operations) and this is where const structure fields would help.

In any case, as I indicated already, I will remove these parts from the patches.
--
Emese
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/