This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] SPU use a 16 byte fpos_t


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.

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?

-- Patrick Mansfield


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]