bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testing for printf bug: please try this with the latest snapshot


From: Jim Meyering
Subject: testing for printf bug: please try this with the latest snapshot
Date: Sat, 27 Oct 2007 10:20:46 +0200

I've added a test for the just-fixed printf bug, included below.
Do any of you know of a system on which the printf _function_
would make the very latest printf from coreutils misbehave?

  ./printf %.2147483647f 1 > /dev/null

With the very latest coreutils and glibc-2.6.1 or 2.7, the above prints:

  ./printf: cannot perform formatted output: Cannot allocate memory

In particular, I'd like to have a little assurance that there
is no printf(3) function implementation that will attempt to
output the 2GB of data.  Then you could argue that printf(1)
is working properly, yet the test would fail (after a long delay).

For your convenience (no new ones) the latest snapshot is here:
  http://meyering.net/cu/coreutils-6.9-ss.tar.gz
  http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig

----------------------

diff --git a/ChangeLog b/ChangeLog
index 7a23e14..8c02585 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2007-10-26  Jim Meyering  <address@hidden>
+
+       Add a test for the printf fix of 2007-10-21.
+       * tests/misc/printf-surprise: New file.  Test for 2007-10-21's fix.
+       * tests/misc/Makefile.am (TESTS): Add printf-surprise.
+
 2007-10-24  Micah Cowan  <address@hidden>

        Remove vestiges of cvs-gnulib-checkout process.  Now we use git.
diff --git a/tests/misc/Makefile.am b/tests/misc/Makefile.am
index 5f256cf..2be132f 100644
--- a/tests/misc/Makefile.am
+++ b/tests/misc/Makefile.am
@@ -83,6 +83,7 @@ TESTS = \
   pathchk1 \
   printf \
   printf-hex \
+  printf-surprise \
   pwd-long \
   readlink-fp-loop \
   runcon-no-reorder \
@@ -116,5 +117,4 @@ TESTS = \
   tty-eof \
   unexpand

-
 include $(top_srcdir)/tests/check.mk
diff --git a/tests/misc/printf-surprise b/tests/misc/printf-surprise
new file mode 100755
index 0000000..03bc73a
--- /dev/null
+++ b/tests/misc/printf-surprise
@@ -0,0 +1,43 @@
+#!/bin/sh
+# Detect printf(3) failure even when it doesn't set stream error indicator
+
+# Copyright (C) 2007 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+prog="$abs_top_builddir/src/printf"
+
+if test "$VERBOSE" = yes; then
+  set -x
+  "$prog" --version
+fi
+
+. $srcdir/../test-lib.sh
+
+fail=0
+
+# The literal width below is 2^31-1.
+# I expect this usage of the printf program to fail.
+# However, it depends on the C library printf function.
+# It could conceivably output "1." and 2GB worth of '0's.
+# You can provoke misbehavior with a much smaller width if you limit
+# virtual memory via, e.g., ulimit -v 10000, but using ulimit would
+# be tricky, since it's not portable.
+"$prog" %.2147483647f 1 > /dev/null 2> err && fail=1
+echo "$prog: cannot perform formatted output: Cannot allocate memory" \
+  > exp || framework_failure
+
+compare err exp || fail=1
+
+(exit $fail); exit $fail
--
1.5.3.4.383.gd90a7




reply via email to

[Prev in Thread] Current Thread [Next in Thread]