grep branch, master, updated. v2.6.3-43-g2018d0e

[Jim Meyering]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "grep".

The branch, master has been updated
       via  2018d0e41f8f2821ed176b71c9e910050c436d94 (commit)
      from  c3f21e894374d071f421215d4f51523fb4816e7d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=2018d0e41f8f2821ed176b71c9e910050c436d94


commit 2018d0e41f8f2821ed176b71c9e910050c436d94
Author: Jim Meyering <address@hidden>
Date:   Fri Apr 16 08:45:58 2010 +0200

    maint: update init.sh and HACKING
    
    * HACKING: Sync from coreutils.
    * tests/init.sh: Update from gnulib.

diff --git a/HACKING b/HACKING
index 31e2347..7857640 100644
--- a/HACKING
+++ b/HACKING
@@ -233,6 +233,107 @@ Try to make the summary line fit one of the following 
forms:
   maint: change-description
 
 
+Curly braces: use judiciously
+=============================
+Omit the curly braces around an "if", "while", "for" etc. body only when
+that body occupies a single line.  In every other case we require the braces.
+This ensures that it is trivially easy to identify a single-*statement* loop:
+each has only one *line* in its body.
+
+Omitting braces with a single-line body is fine:
+
+     while (expr)
+       single_line_stmt ();
+
+However, the moment your loop/if/else body extends onto a second line,
+for whatever reason (even if it's just an added comment), then you should
+add braces.  Otherwise, it would be too easy to insert a statement just
+before that comment (without adding braces), thinking it is already a
+multi-statement loop:
+
+     while (true)
+       /* comment... */      // BAD: multi-line body without braces
+       single_line_stmt ();
+
+Do this instead:
+
+     while (true)
+       {  /* Always put braces around a multi-line body.  */
+         /* explanation... */
+         single_line_stmt ();
+       }
+
+There is one exception: when the second body line is not at the same
+indentation level as the first body line.
+
+     if (expr)
+       error (0, 0, _("a diagnostic that would make this line"
+                      " extend past the 80-column limit"));
+
+It is safe to omit the braces in the code above, since the
+further-indented second body line makes it obvious that this is still
+a single-statement body.
+
+To reiterate, don't do this:
+
+     if (expr)
+       while (expr_2)        // BAD: multi-line body without braces
+         {
+           ...
+         }
+
+Do this, instead:
+
+     if (expr)
+       {
+         while (expr_2)
+           {
+             ...
+           }
+       }
+
+However, there is one exception in the other direction, when even a
+one-line block should have braces.  That occurs when that one-line,
+brace-less block is an "else" block, and the corresponding "then" block
+*does* use braces.  In that case, either put braces around the "else"
+block, or negate the "if"-condition and swap the bodies, putting the
+one-line block first and making the longer, multi-line block be the
+"else" block.
+
+    if (expr)
+      {
+        ...
+        ...
+      }
+    else
+      x = y;    // BAD: braceless "else" with braced "then"
+
+This is preferred, especially when the multi-line body is more than a
+few lines long, because it is easier to read and grasp the semantics of
+an if-then-else block when the simpler block occurs first, rather than
+after the more involved block:
+
+    if (!expr)
+      x = y;                  /* more readable */
+    else
+      {
+        ...
+        ...
+      }
+
+If you'd rather not negate the condition, then add braces:
+
+    if (expr)
+      {
+        ...
+        ...
+      }
+    else
+      {
+        x = y;
+      }
+
+
 Use SPACE-only indentation in all[*] files
 ==========================================
 We use space-only indentation in nearly all files.
@@ -310,9 +411,9 @@ Nearly every significant change must be accompanied by a 
test suite
 addition that exercises it.  If you fix a bug, add at least one test that
 fails without the patch, but that succeeds once your patch is applied.
 If you add a feature, add tests to exercise as much of the new code
-as possible. Note to run tests/newtest in isolation you can do:
+as possible. Note to run tests/new-test in isolation you can do:
 
-  (cd tests && make check TESTS=newtest VERBOSE=yes)
+  (cd tests && make check TESTS=new-test VERBOSE=yes)
 
 There are many tests in the tests/ directories.  Use one of the
 init.sh-using scripts as a template.
diff --git a/tests/init.sh b/tests/init.sh
index 3e3ea44..ee9c542 100644
--- a/tests/init.sh
+++ b/tests/init.sh
@@ -259,7 +259,7 @@ rand_bytes_()
   if test -r "$dev_rand_"; then
     # Note: 256-length($chars_) == 194; 3 copies of $chars_ is 186 + 8 = 194.
     dd ibs=$n_ count=1 if=$dev_rand_ 2>/dev/null \
-      | tr -c $chars_ 01234567$chars_$chars_$chars_
+      | LC_ALL=C tr -c $chars_ 01234567$chars_$chars_$chars_
     return
   fi
 
@@ -276,7 +276,7 @@ rand_bytes_()
 
   echo "$data_" \
     | dd bs=1 skip=50 count=$n_ 2>/dev/null \
-    | tr -c $chars_ 01234567$chars_$chars_$chars_
+    | LC_ALL=C tr -c $chars_ 01234567$chars_$chars_$chars_
 }
 
 mktempd_()
@@ -306,7 +306,7 @@ mktempd_()
   fail=0
 
   # First, try to use mktemp.
-  d=`env -u TMPDIR mktemp -d -t -p "$destdir_" "$template_" 2>/dev/null` \
+  d=`unset TMPDIR; mktemp -d -t -p "$destdir_" "$template_" 2>/dev/null` \
     || fail=1
 
   # The resulting name must be in the specified directory.

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

Summary of changes:
 HACKING       |  105 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 tests/init.sh |    6 ++--
 2 files changed, 106 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
grep