Paul Eggert wrote: > > Well, since I reported > > https://sourceware.org/bugzilla/show_bug.cgi?id=30611 , > > I expect to see a change in glibc behaviour in this area. But binaries > > compiled with a current glibc should continue to work fine with future > > glibc versions. This means, we cannot optimize through a configure test > > here. > > I don't see why we can't optimize. Although Gnulib should be portable to > plausible future changes to glibc, it's implausible that glibc will > return (size_t) -3 for that minor glitch in a rarely used legacy encoding.
I would feel more confident if this would be discussed on libc-alpha sooner than later (since I have a hard time predicting decisions of the glibc developers — such as the decision to prefer pthread_rwlock_rdlock to deadlock for performance reasons, or the refusal to make time() consistent with gettimeofday()). So far, it's only been discussed between you and me. Bruno
