Bug 4099

Summary:	cut utility from GNU coreutils works incorrect
Product:	buildroot	Reporter:	Andrey Kovalev <aka>
Component:	Outdated package	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	normal	CC:	buildroot, uclibc-cvs
Priority:	P5
Version:	2015.02
Target Milestone:	2015.02
Hardware:	All
OS:	Linux
Host:		Target:
Build:

Description Andrey Kovalev 2011-08-28 21:43:49 UTC

GNU coreutils-8.9

Command line: 

echo '3:0:0:' | cut -d : -f 2

Correct output:

0

Compiled with uClibc, output is:

30

I think it is not uClibc bug but coreutils. In coreutils file lib/freadseek.c function freadptrinc looks like stdio hack with a lot of #ifdefs for different libs. stream becomes broken after "fp->__bufpos += increment;" code.

Comment 1 Thomas Petazzoni 2015-08-06 21:59:01 UTC

I confirm that I am able to reproduce the problem with uClibc, but not with glibc.

I reported the bug to upstream uClibc, see http://lists.uclibc.org/pipermail/uclibc/2015-August/049026.html. We'll see if the uClibc developers have some clue.

Comment 2 wbx 2015-08-25 14:55:27 UTC

Hi,

tried on Qemu/arm with coreutils 8.24 and uClibc-ng 1.0.6.
No problem.

best regards

Comment 3 wbx 2015-08-26 12:12:38 UTC

Hi,

okay, found the reason. 
It seems following options in uClibc config fixes the problem:
UCLIBC_HAS_STDIO_GETC_MACRO=y
UCLIBC_HAS_STDIO_PUTC_MACRO=y

They are both disabled in the default config in Buildroot.
In OpenADK, which I used to verify the issue, the options are on.

So no difference which uClibc version is in use.

best regards
 Waldemar

Comment 4 Thomas Petazzoni 2015-08-26 12:43:25 UTC

(In reply to comment #3)
> Hi,
> 
> okay, found the reason. 
> It seems following options in uClibc config fixes the problem:
> UCLIBC_HAS_STDIO_GETC_MACRO=y
> UCLIBC_HAS_STDIO_PUTC_MACRO=y
> 
> They are both disabled in the default config in Buildroot.
> In OpenADK, which I used to verify the issue, the options are on.
> 
> So no difference which uClibc version is in use.

Thanks for the investigation. In other words, you suggest to enable these options in Buildroot as well? The help text of these options says "Most people will answer Y."

(It still seems to be a bug in gnulib to assume that uClibc is always built with those options enabled...)

Comment 5 Thomas Petazzoni 2015-09-21 09:30:55 UTC

Fixed by commits 26ae113d1186951c4969000f5de2ec67e7f1ba3e and e07cc92491080289188b3618d687b06bb9aa6041. Thanks Waldemar!

Comment 6 Pádraig Brady 2015-12-08 16:27:57 UTC

A couple of points.

This gnulib code is quite the layering violation,
which results in issues like these.

It's always worth reporting GNU coreutils bugs to
bug-coreutils@gnu.org

The change to uClibc config is a fine workaround,
especially since it will generally speedup operations,
though the actual fix is probably the following in gnulib:
http://lists.gnu.org/archive/html/bug-gnulib/2015-12/msg00003.html