Peter Van Eynde wrote on Fri, Oct 18, 2002 at 06:00:59PM +0200: > On Fri, Oct 18, 2002 at 08:41:11AM -0400, Martin Cracauer wrote: > > Peter Van Eynde wrote on Fri, Oct 18, 2002 at 12:10:38PM +0200: > > > On Thu, Oct 17, 2002 at 11:52:40AM -0400, Martin Cracauer wrote: > > > > > > > > he code is screwup up in its handlign of errno. > > > > > > > > (unix:unix-open "/tmp/l" 0 0) > > > > NIL > > > > 27 > > > > > > > > errno 27 is "File too big". As long as we don't seek it should't > > > > really matter whether we are in 64 or 32 bit mode, but it does. > > > > > > The direct syscall code uses the 32 bit open, as I thought that without a > > > 64 bit type implementing seeks was going to be painful. > > > > Why? > > > > Normal C programs always use the 64 bit variant of open, as glibc maps > > to it by default. The only reason why lseek is not mapped by default > > as well is that it means an interface change. > > > > So that proves there is no problem with the 64 bits open and 32 bit > > lseek, doesn't it (honest question)? > > The C people find it acceptable that a 32 bit program can open (or even > write) a larger then 2**32 file. They accept that if the program would > ask for the present position in the file it will lose big time.
Correct me if I am wrong, but calling the 32-bit lseek on a file descriptor which has been opend with open64 will work flawlessly, won't it? I'll try later today when I can get some time unless someone already knows the answer. Martin
