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

[Michael Niedermayer]

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

[...]

-- 
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