On Tue, Jun 12, 2007 at 01:39:25AM +0300, Eduard-Gabriel Munteanu wrote: > The cast isn't done right. Doing "fd = (long) dev_id;" doesn't help, > since you pass fd to mconsole_get_request() as is. And > mconsole_get_request() expects an integer: > int mconsole_get_request(int fd, struct mc_request *req)
gcc will trim a long to an integer correctly. You can pass a long to an integer without casting. > This will generate at least a warning on arches where sizeof(int) != > sizeof(long). No it won't. UML builds without warnings here on x86_64. > And by the way, AFAIK, GCC has the habit of breaking compatibility with > some userspace apps when a new GCC major version is released. And, > AFAIK, they're moving towards standards, so relying on GCC's > "guarantees" may backfire. The GCC guarantee I'm talking about it LP64 - I'm highly confident that's not changing any time soon. > >>You're calling glibc functions > >>with that fd as a parameter. On some arches, compiling will issue > >>warnings or simply fail. > > > >Which ones? > > > > An example is sparc64: > quote from > >>http://lxr.linux.no/source/include/asm-sparc64/types.h#L49 What warnings does this produce? These are the same sizes as x86_64 (and every other 64-bit arch that Linux runs on, I bet), where this code compiles without warning. > Really, a kmalloc() isn't such a big deal, it only happens once and > we're not in interrupt context. It's not the runtime cost - it's the extra code. > One the other hand, ensuring safety and > portability on other arches is something that needs to be taken care > of. You haven't demonstrated any safety or portability problems yet. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
