[mplayer-dev at kernel.dk: [MPlayer-dev-eng] [PATCH] sizeof(int) != sizeof(pointer)]

[D Richard Felker III]

On Wed, Mar 12, 2003 at 09:31:21PM +0100, Jens Axboe wrote:
> On Wed, Mar 12 2003, D Richard Felker III wrote:
> > On Wed, Mar 12, 2003 at 01:24:52PM +0100, Jens Axboe wrote:
> > > On Wed, Mar 12 2003, D Richard Felker III wrote:
> > > > On Wed, Mar 12, 2003 at 11:46:10AM +0100, Jens Axboe wrote:
> > > > > 
> > > > > Is someone going to commit this or not? It's clearly a bug.
> > > > > 
> > > > > ----- Forwarded message from Jens Axboe <mplayer-dev at kernel.dk> -----
> > > > > 
> > > > > From: Jens Axboe <mplayer-dev at kernel.dk>
> > > > > Reply-To: mplayer-dev-eng at mplayerhq.hu
> > > > > Date: Tue, 11 Mar 2003 10:39:28 +0100
> > > > > To: mplayer-dev-eng at mplayerhq.hu
> > > > > Subject: [MPlayer-dev-eng] [PATCH] sizeof(int) != sizeof(pointer)
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Should not need a lot of comments, this is pretty basic. Though shallt
> > > > > not cast pointers to ints, on 64-bit archs this is really bad. Below
> > > > > patch fixes segfault on volume up/down for me with mplayer cvs.
> > > > 
> > > > There is definitely a bug but this is not the correct fix. A quick
> > > > glance seems to indicate that the second argument to control() is
> > > > always a pointer, so it should just be declared to take a void *!!!
> > > > 1000l to whoever wrote that mess!
> > > 
> > > Well that is fine, fix it that way if you want. As long as it will hold
> > > a pointer. void * is just as, if not more so, ugly as unsigned long,
> > > though :)
> > 
> > Sorry if you thought the 1000l was for you; it was for whoever
> 
> I don't even know what 1000l means, fwiw...

It means the person gets to drink 1000 liters of cola for writing
broken code. :))

> > originally wrote the mess in libao2. And void * is better, since it's
> > guaranteed to work and unsigned long isn't. (it's possible that
> > unsigned long is not as big as a pointer!)
> 
> void * might be better because it avoids some casts in this case,
> however unsigned long will hold a pointer across all archs I know. In
> fact, lots of software relies on this fact. So there's no difference
> there.

Hmm, I don't see why a 64 bit architecture couldn't use 64 bit
pointers and 32 bit longs... IIRC there's some platform that does this
to avoid breaking programs that assume sizeof(long)==4. Perhaps gcc
always has sizeof(long) >= sizeof(void*), but there's no reason this
should be true in general. (OTOH, we only support gcc anyway.)

Rich