On Sun, Jan 09, 2005 at 12:14:13AM -0800, Neil Parker wrote:
> Jacob Meuser wrote,
> >so I got an amd64 mobo (ASUS KV8 SE Deluxe) and 3000+ CPU.
> >
> >now, I've got a programming question ;)
> >
> >If there's code that does
> >
> > void *data;
> > ...
> > data = (void*)open(...);
> >
> >would it be "fixed" by adding a intptr_t cast?
> >
> > void *data;
> > ...
> > data = (void*)(intptr_t)open(...);
> >
> >it shuts gcc up anyway.
> >
> >where is intptr_t defined on GNU/Linux? it's in <inttypes.h> on
> >OpenBSD.
>
> OK, that's officially weird.
>
> The correct way to fix that code is probably like this:
>
> int data;
> ...
> data = open(...);
yes.
> Remember, open() returns an int (specifically, the file descriptor of the
> file that you just opened).
yes
> I can think of no sensible reason to cast it to
> a pointer--it will never point to anything useful, and deferencing it will
> probably earn you an immediate trip to the land of segmentation violation.
>
> And on an LP64 compiler, casting to a pointer is just plain wrong--ints and
> pointers aren't the same size anymore, and you don't want to shut gcc up,
> because it's trying to tell you something important.
the thing is, there's also a foo_open function, that returns a
pointer to a struct. the code was apparently written to make
open and ibp_open interchangable. since they have different
return types, the author chose to use (void *). the only use
of data is "if(!data) { ... }".
--
<[EMAIL PROTECTED]>
_______________________________________________
EUGLUG mailing list
euglug@euglug.org
http://www.euglug.org/mailman/listinfo/euglug
