index-1.6 stdin bug? & question

Thread View: gnu.utils.bug

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Craig Burley Wed, 09 Sep 1992 20:39

#771

Author: Craig Burley
Date: Wed, 09 Sep 1992 20:39

72 lines
2564 bytes

First, a bugfix, without which indent-1.6 can't reliably read from standard
input:

--------
diff -c io.c.~1~ io.c
*** io.c.~1~	Fri Aug 14 19:09:17 1992
--- io.c	Wed Sep  9 16:27:30 1992
***************
*** 504,509 ****
--- 504,510 ----
  	{
  	  size += (2 * BUFSIZ);
  	  stdinptr.data = xrealloc (stdinptr.data, size);
+ 	  p = stdinptr.data + stdinptr.size;
  	}
      }
    while (ch != EOF);
--------

Second, a question, as a new user of indent:

I get the impression that indent doesn't care at all about the _incoming_
whitespace, i.e. that it doesn't learn anything about the program by looking
at the nature of whitespace.  Is this a correct impression?  (I'm thinking
in terms of the "design" of indent; based on the docs, which I admit I haven't
read in great detail, it looks like it changes whitespace, but doesn't
try and interpret incoming whitespace per se.)

The reason I ask is that I have a situation where a command like

    bash$ indent < foo.c | indent -T bool -T ffelexToken | indent > bar.c

produces a file named bar.c that is different in subtle ways from the
file named baz.c produced by

    bash$ indent < foo.c > baz.c

(where foo.c remains the same in both cases).

Is what I'm observing possible, given the design of indent, or am I seeing
a manifestation of, perhaps, a bug like an uninitialized variable?

The actual differences are limited to cases of the form:

union
  {
    struct
      {
      blah blah blah;
      } xyzzy;
    ...
  } ...

In one file, the xyzzy; is as shown; in the other, it is on a subsequent
line indented so it lines up with the "struct":

    struct
      {
      blah blah blah;
      }
    xyzzy;
    ...

I was trying to determine whether, indenting with no options (i.e. -gnu),
there was any need for me to supply typedef names.  It _seems_ the answer
should be "no", but getting these differences worries me.

Let me know if I'm just missing the boat here, or if I've hit on something
and should send in some sample code (or if you want me to try and debug
this thang)!

        tq vm, (burley)

index-1.6 stdin bug? & question

#791

Author: Joseph Arceneaux
Date: Thu, 10 Sep 1992 16:02

57 lines
2685 bytes

   From: burley@cygnus.com (Craig Burley)
   Date: Wed, 9 Sep 92 16:39:28 EDT

   First, a bugfix, without which indent-1.6 can't reliably read from standard
   input:

This bug has been fixed, along with several others.  Unfortunately, I
do not know when I can make a new release, as Lucid, Inc is severing
my net connection and I don't yet know when I will get another
established.  Hopefully this won't be very long.

   Second, a question, as a new user of indent:

   I get the impression that indent doesn't care at all about the _incoming_
   whitespace, i.e. that it doesn't learn anything about the program by looking
   at the nature of whitespace.  Is this a correct impression?  (I'm thinking
   in terms of the "design" of indent; based on the docs, which I
   admit I haven't 
   read in great detail, it looks like it changes whitespace, but doesn't
   try and interpret incoming whitespace per se.)

I don't think there is a document describing the "design" of indent.
In any event, the "design" is pretty inelegant, and it has been hacked
maliciously over the years.

It is true that indent pays little attention to incoming whitespace.
However, conerning subtle differences in output between various
elements of a chain like:

  indent -st foo.c | indent | indent | indent | ...

I have devoted some effort to ensuring that the output of all elements
is exactly the same.  If it is not, there is a bug.  Note that this
example is not the same as the one you provided:

       bash$ indent < foo.c | indent -T bool -T ffelexToken | indent > bar.c

   produces a file named bar.c that is different in subtle ways from the
   file named baz.c produced by

       bash$ indent < foo.c > baz.c

Identifying typenames with -T *can* change the indentation of your
code, and this is intended.

If you think indent is doing this incorrectly, or there is some other,
related bug, then please send me a minimal example of such code.

Joe

----
Joseph Arceneaux
Free Software Foundation
jla@ai.mit.edu                PO Box 460633
+1 415 285 9088               San Francisco, CA 94146

Help abolish software patents -- send mail for details.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads