Hello, Any updates about this fairly serious bug?
Thanks, Thomas On Thu, 6 Aug 2015 23:57:07 +0200, Thomas Petazzoni wrote: > Hello, > > In Buildroot, we have a long standing bug report that says that the > "cut" program from GNU coreutils doesn't work properly with uClibc: > > https://bugs.busybox.net/show_bug.cgi?id=4099 > > I did the test and indeed an ARM uClibc system exhibits the problem, > but not the ARM glibc system. > > With uClibc, we get the unexpected result: > > # echo "3:0:0" | cut -f2 -d':' > 30 > > With glibc, we get the expected result: > > # echo "3:0:0" | cut -f2 -d':' > 0 > > As analyzed by the person who reported the bug, the issue seems to be > in lib/freadseek.c, which in fact comes from the gnulib project. It > contains some uClibc specific code, which maybe is no longer accurate: > > static void > freadptrinc (FILE *fp, size_t increment) > { > [...] > #elif defined __UCLIBC__ /* uClibc */ > # ifdef __STDIO_BUFFERS > fp->__bufpos += increment; > # else > abort (); > # endif > [...] > } > > I had a very quick look at the uClibc code, and this fp->__bufpos += > increment looks good to me. But still, it fails to work. > > Could someone more knowledgeable about uClibc internals review the > gnulib implementation of this uClibc specific code? > > Thanks, > > Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
