On Mon, 4 Nov 2013, Rich Felker wrote: > > Surely you can create new symbol versions for getrlimit64 and setrlimit64, > > with the old versions just using the 32-bit syscalls (or otherwise > > translating between conventions, but using the 32-bit syscalls is the > > simplest approach)? I see no need to break compatibility with existing > > binaries. > > > > As I noted in > > <https://sourceware.org/ml/libc-ports/2006-05/msg00020.html>, at that time > > the value of RLIM64_INFINITY for o32/n32 was purely a glibc convention the > > kernel didn't see at all. It's only with the use of newer syscalls that > > this glibc convention is any sort of problem. > > Why not just make them convert any value >= 0x7fffffffffffffff to > infinity before making the syscall? There's certainly no meaningful > use for finite values in that range... It might be possible to do such a conversion in setrlimit64 - I'm not sure offhand if such a conversion for large finite values is valid, and a new symbol version is certainly the more conservative option - but getrlimit64 in existing binaries should return results using the existing RLIM64_INFINITY, in case binaries compare against that, so if you change the header value to match the kernel I don't think you can avoid the new symbol version for getrlimit64, and versioning both together seems safer. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx
