[MPlayer-dev-eng] [PATCH] fix scaler on 64 bit

[Rich Felker]

On Fri, May 05, 2006 at 05:56:06PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, May 05, 2006 at 11:27:03AM -0400, Rich Felker wrote:
> > On Fri, May 05, 2006 at 04:20:00PM +0200, Michael Niedermayer wrote:
> > > Hi
> > > 
> > > On Fri, May 05, 2006 at 01:47:38PM +0200, Reimar Döffinger wrote:
> > > > Hi,
> > > > On Fri, May 05, 2006 at 02:26:56PM +0300, Ivan Kalvachev wrote:
> > > > > Wouldn't be (u)intptr_t  better suited?
> > > > 
> > > > Well, I don't really like the fact that then this field of the struct
> > > > would have a different size for 32 and 64 versions. It shouldn't matter
> > > > due to the forced alignment.
> > > > I don't have any strong feelings, but so far I slightly prefer uint64_t.
> > > 
> > > i prefer uint64_t too
> > 
> > Why? intptr_t represents the semantics correctly. uint64_t will break
> > when we port to 128-bit systems. :)
> 
> i dont mind which is used, iam fine with intptr too as long as i dont
> have to implement it ...
> 
> some weak arguments against it:
> * intptr_t IIRC is optional not mandatory part of the C standard
> * intptr_t represents a c ptr, which may or may not be the same as esp
>   (could be segment+offset or something insane like that)
> * esp is 32bit, rsp is 64bit, we store rsp on x86-64 and esp on x86 in
>   that variable ... 
> * the asm code access this by more or less hardcoded offsets, the
>   sizeof(intptr_t) wont make that simpler

OK, I'm not familiar with the issues involved. BTW what on earth is
the asm doing messing with the stack pointer anyway? Is this to use
esp as a general-purpose register? That is NOT SAFE due to signal
handlers using the stack... Only way to make it safe is to block all
signals while this code is running.

Rich