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

Michael Niedermayer michaelni at gmx.at
Sat May 6 02:34:07 CEST 2006


Hi

On Fri, May 05, 2006 at 03:47:10PM -0400, Rich Felker wrote:
> 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.

ideg, i hate linux, why on earth are signal handlers using the normal
stack?! its idiotic, if a program crashes i dont want to have something
random written at a random memory address but want to see the unmodified
stack ...
anyway ill try to remove esp usage, i was unaware that signal handlers
use the "user stack" ....

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the MPlayer-dev-eng mailing list