[PATCH] SPU use a 16 byte fpos_t

[Kazunori Asayama]

Patrick Mansfield <patmans@us.ibm.com> wrote:
> On Thu, Sep 06, 2007 at 10:28:15AM +0900, Kazunori Asayama wrote:
> > Patrick Mansfield <patmans@us.ibm.com> wrote:
> > > fpos_t is 12 bytes for 32 bit ppc glibc, and 16 bytes for 64 bit.
> > > 
> > > Currently SPU newlib uses 4 bytes for fpos_t. This is always a problem
> > > with 64 bit ppc, since the fgetpos() assist call writes 8 bytes back for
> > > the offset, and is a potential problem with 32 bit ppc.
> > > 
> > > So for SPU always use 16 bytes for fpos_t and also make currently unused
> > > (in SPU) _fpos64_t 16 bytes.
> > 
> > Do you have any plan for off_t and size_t ?
> > They have a similar problem to this one.
> 
> But they don't overwrite memory like this, since we pass in 32 bit values
> for off_t and size_t, not the addresses of them.  And the return value for
> lseek is truncated into a 32 bit value (in libspe).
> 
> So it does like there is a problem with lseek and off_t in getting
> truncated return values, that needs a libspe fix. I think we should have
> fix that, add new assist call interfaces to handle 64 bit values, and then
> add large file support for SPU in newlib via the new assist call interfaces.

Do you mean that the newlib should provide both of LFS and non-LFS,
and that applications should be able to switch between LFS and non-LFS
(by _FILE_OFFSET_BITS?) as you said via the cbe-oss-dev ML before?

> 
> Otherwise, I don't think ssize_t or size_t have bugs, since right now we
> can only set 32 bit values in newlib, and readv/writev are checking for
> overflow.
> 
> There is also truncation of some of the jsre stat values (for 64 bit glibc
> ppc), none of them look bad, they could be truncated but you would need
> some code on the linux side to use the upper 32 bits (for dev/rdev, time,
> nlink, and ino), I don't think that is possible right now (like time
> overflowing, having kernel major/minor be 64 bits, and such).
> 
> But are you OK with this fpos_t patch?

Yes, please go ahead.

--
(ASAYAMA Kazunori
  (asayama@sm.sony.co.jp))
t