This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> First, the LFS proposal will probably be adopted for the next revision > of the Unix standards and since it'll be merged with POSIX the latter > will also have it. But it don't yet. Anyway, the rationale for sysdeps/ layout is not for definitional purism, it's for convenience of porting and sharing code. > Second, I see this rather as POSIX-like function should be used. > POSIX does not demand that all of the functions it includes are > defined on all systems and therefore you cannot write functions in > sysdeps/posix as if all interfaces are available. That sounds like a contradiction of your first argument. Indeed, that you cannot expect lseek64 to be available is exactly my (first) complaint and reason that sysdeps/posix code should not use it. > > I think it is dangerously misleading to provide an incorrect > > implementation instead of none at all. > > I don't see a danger here. Ha! You are not that naive. The nature of the danger is introduction of subtle race condition bugs when noone suspects the issue may have arisen. > If you have a system with threads you better have a pread syscall (or > equivalent). Is it not the case that there are Linux kernels where linuxthreads can work but there is no pread? I'm pretty sure that was the case at one time, anyway. > If you don't have threads the replacement is not too bad. If you don't have pthreads then why would you expect to have pread at all? It's certainly not a portable expectation. > If you really want to see this removed I wouldn't object strongly but so > far I have no seen a convincing argument. Well, you know me; I made the old college try at the theroetical reasons first, but I only really care about the pragmatic issue that something is now broken in 2.1 for the hurd. (I already implemented pread/pwrite for the hurd in 2.2, but left new features out of 2.1 as seemed proper.) Something else I haven't tracked down yet appears to have newly changed so the bogus pread is being linked in where it wasn't before, and I haven't looked into what it is yet.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |