I looked through 2.3.16 and I noticed there were some left. These are
places where some implementations of TIOC* macros write a 'long' into
the user address space, even though most other implementations (of the
same macros) write an 'int'. Also mgetty and every user-space program
that I have seen uses 'int'.
Attached is a list. When I get some more free time, like in 2000,
I'll write up patches.
I know RS-232 serial on 64-bit machines is obsolete and boring, but
I have a real dislike for int/long sloppiness. I lived through the
Michael Elizabeth Chastain
"love without fear"
drivers/char/cyclades.c: TIOCMBIS TIOCMBIC TIOCMSET
look at the call chain: cy_ioctl -> set_modem_info -> cy_get_user.
cy_get_user always reads a long no matter what its argument type.
It also doesn't return -EINVAL on address space errors; instead,
something random will happen.
drivers/char/epca.c: TIOCMGET TIOCGSOFTCAR TIOCSSOFTCAR
More macro funnies. Look carefully at the definitions of putUser
TIOCSERGWILD appears to be a meaningless ioctl in all the other drivers
(returns 0 or not implemented), so it could either disappear or
at least return a 0 of the same size as the others.
drivers/char/isicom.c: TIOCMBIS TIOCMBIC TIOCMSET TIOCGSOFTCAR TIOCSSOFTCAR
cloned from cyclades.c, same cy_get_user schmutz.
drivers/char/specialix.c: TIOCMBIS TIOCMBIC TIOCMSET TIOCGSOFTCAR TIOCSSOFTCAR
sx_set_modem_info verifies an int, then reads a long!
drivers/sbus/char/aurora.c: TIOCMGET TIOCGSOFTCAR TIOCSSOFTCAR
just read aurora_get_modem_info. A bunch of decoy casts lead up to
the final put_user(result,(unsigned long *)value).
drivers/isdn/isdn_tty.c: TIOCGSOFTCAR TIOCSSOFTCAR
drivers/sbus/char/zs.c: TIOCGSOFTCAR TIOCSSOFTCAR
drivers/sgi/char/sgiserial.c: TIOCGSOFTCAR TIOCSSOFTCAR
Dang. All told, 8 drivers read/write these as long. But about 15
others read/write them as int.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/