[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    Re: Coreutils "cut" not working with uClibc
From:       Thomas Petazzoni <thomas.petazzoni () free-electrons ! com>
Date:       2015-08-24 20:48:16
Message-ID: 20150824224816.1853c44d () free-electrons ! com
[Download RAW message or body]

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
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[prev in list] [next in list] [prev in thread] [next in thread]