Re: [PATCH] Do not drop 'nocast' modifier when taking the address.

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Wed, Feb 03, 2016 at 12:09:16PM +0800, Christopher Li wrote:
> On Wed, Feb 3, 2016 at 11:43 AM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> pped.
> >
> > The nocast mod is dropped and lost in the function create_pointer().
> > In the example above, "cputime_t *" has type :
> >         unsigned long [nocast] [usertype] *
> > while &utime is just:
> >         unsigned long *
> 
> That is my point. Why does "&utime" get drop but "cputime_t *" does not?
> They both are pointer of a base type. They both create pointers.

Well with "cputime_t *" you got the pointer directly, by its own declaration;
with "&utime" you really _create_ one with the "&"/"addressof" operator.

The function "create_pointer()" is only called when evaluating an expression
using the addressof operator or when when an array of a function is degenerated
into a pointer.

> It seems to me the bug is sparse not treating this two case consistently.
> 
> > So, for sparse and its extended notion of type, the type we get when
> > taking the address of a [variable of some] type X is not the same as
> > directly using a pointer to the type X.
> 
> In C language type system,  these two should be the same type. It is a
> bug in sparse if they are not. I would rather get that bug fixed.

They _have_ the same type if we limit ourselves to the pure C type system,
but they differ once we look also at the sparse & gcc extension to the
type system, like the nocast attribute here.
 
Now, whether they should be the same or not is a question of defining the
semantic of the addressof operator on sparse's type extension.

> > Which is very fine, just that MOD_NOCAST is dropped while the example
> > shows that it should not.
> 
> I think that is a separate issue weather MOD_NOCAST should be inherent
> from pointer base type.

I'm not sure to understand you here.

> Same with MOD_STORAGE.
> 
> Chris

Luc