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

[Michael Niedermayer]

Hi

On Sat, May 06, 2006 at 02:34:07AM +0200, Michael Niedermayer wrote:
> 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

done

[...]
-- 
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