home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / gnu / utils / bug / 1523 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.4 KB  |  87 lines
  1. Newsgroups: gnu.utils.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!cygnus.com!burley
  3. From: burley@cygnus.com (Craig Burley)
  4. Subject: index-1.6 stdin bug? & question
  5. Message-ID: <9209092039.AA03285@tweedledumb.cygnus.com>
  6. Sender: gnulists@ai.mit.edu
  7. Reply-To: burley@gnu.ai.mit.edu
  8. Organization: GNUs Not Usenet
  9. Distribution: gnu
  10. Date: Wed, 9 Sep 1992 20:39:28 GMT
  11. Approved: bug-gnu-utils@prep.ai.mit.edu
  12. Lines: 73
  13.  
  14. First, a bugfix, without which indent-1.6 can't reliably read from standard
  15. input:
  16.  
  17. --------
  18. diff -c io.c.~1~ io.c
  19. *** io.c.~1~    Fri Aug 14 19:09:17 1992
  20. --- io.c    Wed Sep  9 16:27:30 1992
  21. ***************
  22. *** 504,509 ****
  23. --- 504,510 ----
  24.       {
  25.         size += (2 * BUFSIZ);
  26.         stdinptr.data = xrealloc (stdinptr.data, size);
  27. +       p = stdinptr.data + stdinptr.size;
  28.       }
  29.       }
  30.     while (ch != EOF);
  31. --------
  32.  
  33. Second, a question, as a new user of indent:
  34.  
  35. I get the impression that indent doesn't care at all about the _incoming_
  36. whitespace, i.e. that it doesn't learn anything about the program by looking
  37. at the nature of whitespace.  Is this a correct impression?  (I'm thinking
  38. in terms of the "design" of indent; based on the docs, which I admit I haven't
  39. read in great detail, it looks like it changes whitespace, but doesn't
  40. try and interpret incoming whitespace per se.)
  41.  
  42. The reason I ask is that I have a situation where a command like
  43.  
  44.     bash$ indent < foo.c | indent -T bool -T ffelexToken | indent > bar.c
  45.  
  46. produces a file named bar.c that is different in subtle ways from the
  47. file named baz.c produced by
  48.  
  49.     bash$ indent < foo.c > baz.c
  50.  
  51. (where foo.c remains the same in both cases).
  52.  
  53. Is what I'm observing possible, given the design of indent, or am I seeing
  54. a manifestation of, perhaps, a bug like an uninitialized variable?
  55.  
  56. The actual differences are limited to cases of the form:
  57.  
  58. union
  59.   {
  60.     struct
  61.       {
  62.       blah blah blah;
  63.       } xyzzy;
  64.     ...
  65.   } ...
  66.  
  67. In one file, the xyzzy; is as shown; in the other, it is on a subsequent
  68. line indented so it lines up with the "struct":
  69.  
  70.     struct
  71.       {
  72.       blah blah blah;
  73.       }
  74.     xyzzy;
  75.     ...
  76.  
  77. I was trying to determine whether, indenting with no options (i.e. -gnu),
  78. there was any need for me to supply typedef names.  It _seems_ the answer
  79. should be "no", but getting these differences worries me.
  80.  
  81. Let me know if I'm just missing the boat here, or if I've hit on something
  82. and should send in some sample code (or if you want me to try and debug
  83. this thang)!
  84.  
  85.         tq vm, (burley)
  86.  
  87.