GNU bug report logs - #17012
[3 PATCHES] Whitespace cleanup : Replace code-alignment tabs with spaces.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17012 in the body.
You can then email your comments to 17012 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: behoffski <behoffski <at> grouse.com.au>
To: bug-grep <at> gnu.org
Subject: [3 PATCHES] Whitespace cleanup : Replace code-alignment tabs with
 spaces.
Date: Fri, 14 Mar 2014 20:33:28 +1030

[Message part 1 (text/plain, inline)]

G'day,

I've been looking at the grep sources with various tools, and have found on a
couple of occasions that tab characters (ASCII code 09, ^I) confused me where
they occurred in the code.  For example, in commit ...c73ca06859c0820d9d,
Paul Eggert had to pacify "make dist", which calls "make syntax-check", as a
line had leading tabs:

         * src/dfa.c (parse_bracket_exp): Reindent with spaces.

I've worked on other projects where consistent and concise code formatting is
stringently applied (usually as code commit hooks that run Perl scripts), and
have found this environment useful, as there is a "canonical" representation
of the source to refer to.  GNU grep has made several steps in this direction
(e.g. no leading tabs, no trailing whitespace), but the translation isn't
complete:  Tabs still appear in a few selected places in the code.

One easy way to spot tab characters in C sources (merely .c and .h files here)
is to use "cat -T", which replaces the horizontal tab character with "^I":

        for f in *.[ch] ; do
                TMPFILE =`mktemp`
                echo "$f" ; cat -T "$f" >"$TMPFILE" ;        \
                       diff "$f" "$TMPFILE" ; rm -f "$TMPFILE"
        done

Another way (ASCII) is to look for hex code "09" in an octal dump of a source:

        for f in *.[ch] ; do
                echo "$f" ; od -txC "$f" | grep " 09"
        done

Attached are three small, concise patches, each changing one file in the
grep/src directory (I'm not daring to tackle gnulib at present).  These are
small, self-contained and should be fairly easy to review.  The files
modified are grep.h, kwset.h and dosbuf.c.

Please let me know if these changes are considered to be worthwhile, and,
if so, I'll submit larger patches for kwset.c, main.c and dfa.c.

cheers,

behoffski (Brenton Hoff)
Programmer, Grouse Software

[maint-dosbuf.c-tabs-spaces.patch (text/x-patch, attachment)]

[maint-grep.h-tabs-spaces.patch (text/x-patch, attachment)]

[maint-kwset.h-tabs-spaces.patch (text/x-patch, attachment)]

Message #8 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: behoffski <behoffski <at> grouse.com.au>, 17012 <at> debbugs.gnu.org
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment
 tabs with spaces.
Date: Fri, 14 Mar 2014 07:36:50 -0700

behoffski wrote:
> One easy way to spot tab characters in C sources

This is grep, right?  So we should use "grep '	'".

Jim Meyering has the strongest feeling about tabs, so I assume he'll 
pick this one up.

Message #11 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17012 <at> debbugs.gnu.org, behoffski <behoffski <at> grouse.com.au>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace
 code-alignment tabs with spaces.
Date: Fri, 14 Mar 2014 09:12:12 -0700

On Fri, Mar 14, 2014 at 7:36 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> behoffski wrote:
>>
>> One easy way to spot tab characters in C sources
>
>
> This is grep, right?  So we should use "grep '  '".
>
> Jim Meyering has the strongest feeling about tabs, so I assume he'll pick
> this one up.

Hi Brenton,

I do indeed have strong feelings about tabs :-)
Like remove all leading ones, and any TAB-after-space.
[rules to enforce that are in maint.mk and cfg.mk]
However, a few times when a crusade led me to do
what you're proposing and eliminate all of them, I later realized
that I found value in TAB-aligned comments, and actually regretted
performing that particular TAB->SP+ conversion.

On a code normalization front, I am inclined to fully automate the
process, and have spent time (though not recently) trying to find
the combination of settings in the uncrustify tool that recreate the
style we use in a few projects. If you feel like pursuing this, please
look at uncrustify and see if you can minimize the changes required
to move grep to something uncrustify-generated.

Bottom line, I'm not terribly keen on changing comment-aligning
tabs to spaces.

Thanks,
Jim

Message #14 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: 17012 <at> debbugs.gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment
 tabs with spaces.
Date: Fri, 14 Mar 2014 13:58:04 -0500

Jim Meyering wrote:
> On Fri, Mar 14, 2014 at 7:36 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>> behoffski wrote:
>>>
>>> One easy way to spot tab characters in C sources
>>
>>
>> This is grep, right?  So we should use "grep '  '".
>>
>> Jim Meyering has the strongest feeling about tabs, so I assume he'll pick
>> this one up.
>
> Hi Brenton,
>
> I do indeed have strong feelings about tabs :-)
> Like remove all leading ones, and any TAB-after-space.
> [rules to enforce that are in maint.mk and cfg.mk]
> However, a few times when a crusade led me to do
> what you're proposing and eliminate all of them, I later realized
> that I found value in TAB-aligned comments, and actually regretted
> performing that particular TAB->SP+ conversion.
>
> On a code normalization front, I am inclined to fully automate the
> process, and have spent time (though not recently) trying to find
> the combination of settings in the uncrustify tool that recreate the
> style we use in a few projects. If you feel like pursuing this, please
> look at uncrustify and see if you can minimize the changes required
> to move grep to something uncrustify-generated.
>
> Bottom line, I'm not terribly keen on changing comment-aligning
> tabs to spaces.

Tabs in code are indeed evil.  Different users have different tab stops.
I would convert *all* tabs to spaces and add to each file:

/* -*- tab-width:8; intent-tabs-mode:nil;  -*- */
/* ex: set tabstop=8 expandtab: */

A lot of people make a lot of effort to make their code look good.  Then
someone makes a change and uses a different tab setting and makes it 
look ugly, either in a pager or an editor.

Bottom line is to not permit patches with tabs.

  -- Bruce Dubbs
     linuxfromscratch.org

P.S.  There was a considerable amount of research in the 1980s that
investigated cognitive interpretation of code at different tab stops. 
The general conclusion was that between 2 and 4 spaces maximizes 
comprehension.

Message #17 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace
 code-alignment tabs with spaces.
Date: Fri, 14 Mar 2014 21:04:14 -0700

On Fri, Mar 14, 2014 at 11:58 AM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
> Jim Meyering wrote:
>>
>> On Fri, Mar 14, 2014 at 7:36 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>>>
>>> behoffski wrote:
>>>>
>>>>
>>>> One easy way to spot tab characters in C sources
>>>
>>>
>>>
>>> This is grep, right?  So we should use "grep '  '".
>>>
>>> Jim Meyering has the strongest feeling about tabs, so I assume he'll pick
>>> this one up.
>>
>>
>> Hi Brenton,
>>
>> I do indeed have strong feelings about tabs :-)
>> Like remove all leading ones, and any TAB-after-space.
>> [rules to enforce that are in maint.mk and cfg.mk]
>> However, a few times when a crusade led me to do
>> what you're proposing and eliminate all of them, I later realized
>> that I found value in TAB-aligned comments, and actually regretted
>> performing that particular TAB->SP+ conversion.
>>
>> On a code normalization front, I am inclined to fully automate the
>> process, and have spent time (though not recently) trying to find
>> the combination of settings in the uncrustify tool that recreate the
>> style we use in a few projects. If you feel like pursuing this, please
>> look at uncrustify and see if you can minimize the changes required
>> to move grep to something uncrustify-generated.
>>
>> Bottom line, I'm not terribly keen on changing comment-aligning
>> tabs to spaces.
>
>
> Tabs in code are indeed evil.  Different users have different tab stops.
> I would convert *all* tabs to spaces and add to each file:
>
> /* -*- tab-width:8; intent-tabs-mode:nil;  -*- */
> /* ex: set tabstop=8 expandtab: */

For the record, I think that such comments should be made unnecessary.
I.e., maintain coding standards with enough automated infrastructure
that that type of crutch is not required.  See the guidelines in coreutils'
HACKING file.  Speaking of which, grep's HACKING needs a refresher.

> A lot of people make a lot of effort to make their code look good.  Then
> someone makes a change and uses a different tab setting and makes it look
> ugly, either in a pager or an editor.
>
> Bottom line is to not permit patches with tabs.
>
>   -- Bruce Dubbs
>      linuxfromscratch.org
>
> P.S.  There was a considerable amount of research in the 1980s that
> investigated cognitive interpretation of code at different tab stops. The
> general conclusion was that between 2 and 4 spaces maximizes comprehension.

That is why we impose the existing no-TAB rules.
The few remaining ones, for comment alignment, not code alignment,
are less problematic.

Message #20 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment
 tabs with spaces.
Date: Fri, 14 Mar 2014 23:32:21 -0500

Jim Meyering wrote:

>> Tabs in code are indeed evil.  Different users have different tab stops.
>> I would convert *all* tabs to spaces and add to each file:
>>
>> /* -*- tab-width:8; intent-tabs-mode:nil;  -*- */
>> /* ex: set tabstop=8 expandtab: */
>
> For the record, I think that such comments should be made unnecessary.
> I.e., maintain coding standards with enough automated infrastructure
> that that type of crutch is not required.  See the guidelines in coreutils'
> HACKING file.  Speaking of which, grep's HACKING needs a refresher.

Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING 
file.  It's not in the coreutils-8.17 tarball either.  It is in the git 
tree though.

  -- Bruce

Message #23 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace
 code-alignment tabs with spaces.
Date: Fri, 14 Mar 2014 21:44:32 -0700

On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
...
>> For the record, I think that such comments should be made unnecessary.
>> I.e., maintain coding standards with enough automated infrastructure
>> that that type of crutch is not required.  See the guidelines in
>> coreutils'
>> HACKING file.  Speaking of which, grep's HACKING needs a refresher.
>
> Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING
> file.  It's not in the coreutils-8.17 tarball either.  It is in the git tree
> though.

FYI, that is deliberate.
You can get it here, too:

  http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING

If you're hacking on coreutils (as with most pkgs), you should be doing
so via a git clone, with the very latest, not starting from a tarball,
which is almost always out of date by at least a few commits.

Message #26 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Bruce Dubbs <bruce.dubbs <at> gmail.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment
 tabs with spaces.
Date: Sat, 15 Mar 2014 00:03:07 -0500

Jim Meyering wrote:
> On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
> ...
>>> For the record, I think that such comments should be made unnecessary.
>>> I.e., maintain coding standards with enough automated infrastructure
>>> that that type of crutch is not required.  See the guidelines in
>>> coreutils'
>>> HACKING file.  Speaking of which, grep's HACKING needs a refresher.
>>
>> Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING
>> file.  It's not in the coreutils-8.17 tarball either.  It is in the git tree
>> though.
>
> FYI, that is deliberate.
> You can get it here, too:
>
>    http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>
> If you're hacking on coreutils (as with most pkgs), you should be doing
> so via a git clone, with the very latest, not starting from a tarball,
> which is almost always out of date by at least a few commits.

That makes sense, but I'd think that the above sentence should be in the 
tarball in a fairly prominent location.  I see a reference to
README-hacking and HACKING in the README file, but it's not clear that 
those are only available via git clone.

  -- Bruce

Message #29 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Bruce Dubbs <bruce.dubbs <at> gmail.com>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace
 code-alignment tabs with spaces.
Date: Sat, 15 Mar 2014 11:46:34 -0700

On Fri, Mar 14, 2014 at 10:03 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
...
>> FYI, that is deliberate.
>> You can get it here, too:
>>
>>    http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>>
>> If you're hacking on coreutils (as with most pkgs), you should be doing
>> so via a git clone, with the very latest, not starting from a tarball,
>> which is almost always out of date by at least a few commits.
>
> That makes sense, but I'd think that the above sentence should be in the
> tarball in a fairly prominent location.  I see a reference to
> README-hacking and HACKING in the README file, but it's not clear that those
> are only available via git clone.

Just after the sentence in README that mentions those two other files,
you will find tips on reporting and fixing problems, including this:

    Here are instructions for checking out the latest development sources:

      http://savannah.gnu.org/git/?group=coreutils

Or just google "coreutils hacking".

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Johannes Meixner <jsmeix <at> suse.de>
To: bug-grep <at> gnu.org
Cc: 17012 <17012 <at> debbugs.gnu.org>, bug-grep <at> gnu.org,
 Bruce Dubbs <bruce.dubbs <at> gmail.com>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace code-alignment
 tabs with spaces.
Date: Tue, 18 Mar 2014 10:02:04 +0100 (CET)

Hello,

On Mar 14 21:44 Jim Meyering wrote (excerpt):
> On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com> wrote:
>>> See the guidelines in coreutils' HACKING file.
...
>> Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING
>> file.  It's not in the coreutils-8.17 tarball either.  It is in the git tree
>> though.
>
> FYI, that is deliberate.
> You can get it here, too:
>
>  http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>
> If you're hacking on coreutils (as with most pkgs), you should be doing
> so via a git clone, with the very latest, not starting from a tarball,
> which is almost always out of date by at least a few commits.

I agree for real upstream developers (i.e. who work as authors).

But for casual external contributors it could be different:

In particular experienced users that have it installed as binary
software package from a (Linux) distributor (e.g. as RPM package).

Those users may find an issue and then install the matching source
package (e.g. a source RPM) so that they get the matching tarball
of their currently installed binary software, then change
that sources and provide a bugreport with patch to upstream.

I think it won't hurt when even the binary software package contains
such files as documentation. If for example coreutils' HACKING file
would be installed as documentation, at least some experienced users
may find and read it and contribute to upstream accordingly.

In general I think the installed documentation should be complete.

For example the coreutils README file could provide more specific
information how to contribute correctly to upstream.

My currently installed coreutils-8.22 README file
(from an openSUSE coreutils-8.22 RPM package) contains
------------------------------------------------------------------------
If you obtained this file as part of a "git clone", then see the
README-hacking file.  If this file came to you as part of a tar archive,
then see the file INSTALL for compilation and installation instructions.
...
Send bug reports, questions, comments, etc. to bug-coreutils <at> gnu.org.
If you would like to suggest a patch, see the files README-hacking
and HACKING for tips.
------------------------------------------------------------------------
but I neither have README-hacking nor INSTALL nor HACKING installed.

Therefore the installed coreutils documentation looks incomplete from
my point of view regardless that it is probably considered correct
from upstream's point of view.

Perhaps this is a packaging issue because the openSUSE coreutils RPM
coreutils.spec file basically contains
------------------------------------------------------------------------
%install
...
make install DESTDIR="%buildroot" pkglibexecdir=%{_libdir}/%{name}
.
.
.
%files
...
%doc COPYING NEWS README THANKS
------------------------------------------------------------------------
see
https://build.opensuse.org/package/view_file/Base:System/coreutils/coreutils.spec?expand=1

According to the INSTALL file in my coreutils-8.22 tarball
a plain "make install" should do "the right thing":
------------------------------------------------------------------------
  4. Type `make install' to install the programs and any data files and
     documentation. 
------------------------------------------------------------------------

As far as I see it seems by default there is no documentation installed
(except man pages) which means that each coreutils distributor installs
a different set of documentation files.

I assume this is intended but I do not understand the reason behind.

By the way:
I wonder why is there no INSTALL file in the coreutils
git source repository at git://git.sv.gnu.org/coreutils

I assume all this is intended and there are good reasons for it
but from my point of view it looks somehow strange.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer

Message #38 received at 17012 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Johannes Meixner <jsmeix <at> suse.de>
Cc: 17012 <17012 <at> debbugs.gnu.org>, Coreutils <coreutils <at> gnu.org>
Subject: Re: bug#17012: [3 PATCHES] Whitespace cleanup : Replace
 code-alignment tabs with spaces.
Date: Tue, 18 Mar 2014 18:32:53 -0700

On Tue, Mar 18, 2014 at 2:02 AM, Johannes Meixner <jsmeix <at> suse.de> wrote:
> On Mar 14 21:44 Jim Meyering wrote (excerpt):
>>
>> On Fri, Mar 14, 2014 at 9:32 PM, Bruce Dubbs <bruce.dubbs <at> gmail.com>
>> wrote:
>>>>
>>>> See the guidelines in coreutils' HACKING file.
>
> ...
>
>>> Interesting.  Looking at the coreutils-8.22 tarball, there is no HACKING
>>> file.  It's not in the coreutils-8.17 tarball either.  It is in the git
>>> tree
>>> though.
>>
>>
>> FYI, that is deliberate.
>> You can get it here, too:
>>
>>  http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING
>>
>> If you're hacking on coreutils (as with most pkgs), you should be doing
>> so via a git clone, with the very latest, not starting from a tarball,
>> which is almost always out of date by at least a few commits.
>
> I agree for real upstream developers (i.e. who work as authors).
>
> But for casual external contributors it could be different:
>
> In particular experienced users that have it installed as binary
> software package from a (Linux) distributor (e.g. as RPM package).
>
> Those users may find an issue and then install the matching source
> package (e.g. a source RPM) so that they get the matching tarball
> of their currently installed binary software, then change
> that sources and provide a bugreport with patch to upstream.
>
> I think it won't hurt when even the binary software package contains
> such files as documentation. If for example coreutils' HACKING file
> would be installed as documentation, at least some experienced users
> may find and read it and contribute to upstream accordingly.

This might help.  I've Cc'd the coreutils discussion list.

> In general I think the installed documentation should be complete.
>
> For example the coreutils README file could provide more specific
> information how to contribute correctly to upstream.
>
> My currently installed coreutils-8.22 README file
> (from an openSUSE coreutils-8.22 RPM package) contains
> ------------------------------------------------------------------------
> If you obtained this file as part of a "git clone", then see the
> README-hacking file.  If this file came to you as part of a tar archive,
> then see the file INSTALL for compilation and installation instructions.
> ...
> Send bug reports, questions, comments, etc. to bug-coreutils <at> gnu.org.
> If you would like to suggest a patch, see the files README-hacking
> and HACKING for tips.
> ------------------------------------------------------------------------
> but I neither have README-hacking nor INSTALL nor HACKING installed.

Those things are typically useful to tarball(INSTALL) or cloned-sources
consumers, but as mentioned, at least README-hacking and HACKING
may help a few new contributors get started.

> Therefore the installed coreutils documentation looks incomplete from
> my point of view regardless that it is probably considered correct
> from upstream's point of view.
>
> Perhaps this is a packaging issue because the openSUSE coreutils RPM
> coreutils.spec file basically contains
> ------------------------------------------------------------------------
> %install
> ...
> make install DESTDIR="%buildroot" pkglibexecdir=%{_libdir}/%{name}
> .
> .
> .
> %files
> ...
> %doc COPYING NEWS README THANKS
> ------------------------------------------------------------------------
> see
> https://build.opensuse.org/package/view_file/Base:System/coreutils/coreutils.spec?expand=1
>
> According to the INSTALL file in my coreutils-8.22 tarball
> a plain "make install" should do "the right thing":
> ------------------------------------------------------------------------
>   4. Type `make install' to install the programs and any data files and
>      documentation.
> ------------------------------------------------------------------------
>
> As far as I see it seems by default there is no documentation installed
> (except man pages) which means that each coreutils distributor installs
> a different set of documentation files.

Installed by "make install"?  That installs the build doc/*.info files, too.
Those constitute the primary documentation.

> I assume this is intended but I do not understand the reason behind.
>
> By the way:
> I wonder why is there no INSTALL file in the coreutils
> git source repository at git://git.sv.gnu.org/coreutils

It is imported from the gnulib submodule when you run
./bootstrap, as you must when building from cloned sources.

> I assume all this is intended and there are good reasons for it
> but from my point of view it looks somehow strange.
>
> Kind Regards
> Johannes Meixner

Thanks for the feedback.

Message #45 received at 17012-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17012-done <at> debbugs.gnu.org
Subject: Re: [3 PATCHES] Whitespace cleanup : Replace code-alignment tabs
 with spaces.
Date: Sat, 05 Apr 2014 22:34:16 -0700

As the original issue here seems to have been resolved with a "that's 
not a bug", I'm closing the report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.