Re: Reverse the ucdrom.h patch in 2.1.12

Linus Torvalds (
Fri, 22 Nov 1996 21:09:44 +0200 (EET)

On Fri, 22 Nov 1996, Erik B. Andersen wrote:
> In patch-2.1.12, linux/include/linux/ucdrom.h was changed based on the
> posting of Gerd Knorr to linux-kernel. I subsequently pointed out that
> this is the WrongWay(tm) to fix the problem, as this very issue was
> discussed some time ago in private email. The values for speed and
> capacity SHOULD be declared const, as these values should not be messed
> with by anything. However, since these values must be set on drive
> initialization, and the method utilized in ide-cd to avoid the compilation
> warnings works just fine.

Hmm.. Personally, I consider pointer casts a bug by default, which was why
I applied the non-cast version instead.

If pointer casts are needed, I'd much prefer them done through another
interface, one such being for example:


with initialize_cdrom() being a inline function or whatever that then does
the casting.

The _reason_ I consider pointer casts a bug is that they mess with the C
type checking. "What type checking?" I hear you say.. But in fact C type
checking is very practical if done correctly, and one reason I use "-Wall"
with gcc for everything I write. If the stuff is ever changed (to use
"long" for example), the code that uses casts will never result in a
compiler warning, yet it will be hopelessly incorrect unless fixed.

Now, a inline function that does the same cast results in the same _code_,
but then the cast is hidden in one place (and if the inline function is
placed near enough the definition of the types, anybody who changes the
type is likely to change the inline function to mess with the type as

If you think I'm looking for something like objects but without the
overhead of a object-oriented language, you're getting pretty close.

Thought of the day: "Any interface that _requires_ the programmer to use
a cast is a bad interface".

Anybody want to send me patches?