Blaz writes:
> Hmm, I thought that L in first line and (unsigned long) in second
> line sets the appropriate data width. I mean L is always used with
> long constants while (type) is used for variables.
Actually, I added the "L". It is not in the original code at
line 344 of fs/select.c.
But the data width of interest is the value returned by get_user().
Note that the real problem in get_user() is because it is defined by
peekw() which is a function that returns an integer. The peekw()
function is written in assembly language (see arch/i86/lib/peekw.s)
and it is impossible to get it to return a long because of the tricky
way it returns from a call (clobbering registers that could be used
to return a long).
What is needed is a similar function, perhaps peekd() which
would return a long. Then we could define a macro get_user_long()
in terms of peekd(). As far as I can tell, there is no 32 bit
version of peekw() or get_user(). I favor naming the macro
get_user_long() rather than overloading get_user() for different
data types. It is clearer that way and less prone to error like
we have now.
In any case, the code at lines 344,345 is broken and needs fixing
because get_user() is returning the wrong data.
> it's word wide and sometimes it is byte wide. Both (actually all
> three, including 32 bit) should be defined somewhere
I'm aware of peekb() for "db" 8 bit byte data, and peekw for "dw"
16 bit word data, but I'm unable to find a peekd() for "dd"
32 bit double word data. As far as I can tell, there isn't one.
later,
Thomas
[EMAIL PROTECTED]
