HDTenEightyP/NetNews huggingface dataset:
From: epperly@valeron.che.wisc.edu (Tom Epperly)
Subject: fontutils-0.5 installation warnings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 18:00:00 GMT

GNU FontUtils Version: 0.5
DECstation 3100, Ultrix V4.2 (Rev. 96)
Compiler: gcc Version 2.2.2

Warnings about NULL being redefined.  For example:

gcc -O -g -I.././include -I/home/X11R5/include -c xstat.c
In file included from .././include/c-memstr.h:27, from .././include/config.h:34, from xstat.c:19:
/usr/include/string.h:53: warning: `NULL' redefined
/usr/local/lib/gcc-lib/decstation/2.1/include/stddef.h:105: warning: this is the location of the previous definition

Newsgroups: gnu.utils.bug
From: burley@gnu.ai.mit.edu (Craig Burley)
Subject: index-1.6 stdin bug? & question
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 17:47:15 GMT

>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.

Yes, I know -T can change the indentation of the code.  In my case, it did.
But wouldn't the _last_ indent (the "| indent > bar.c") change it back,
since it doesn't have the same -T information?  What surprises me is that
it doesn't appear to -- the output stays the same as if, in place of that
quoted part, "> bar.c" were provided so as to direct the output of the indent
with the -T options into bar.c.

If _this_ is not what you'd expect, I'll make a small example (should be easy,
though the file I'm working with is huge) and send it along!

Sorry about your net connections...will you be able to maintain modem
connections to the FSF or, say, Cygnus from home?  I'm running Linux on a
486 machine, using kermit, dialed into a Cygnus machine in Boston, and that's
working pretty well.  (I had to sign a nondisc agreement with Cygnus, but
that's no big deal for me.)  Sometimes the modem is busy, because two or
three others have access to it -- though typically only one person uses it
from around 1am-9am or so.

Anyway, with a 386/16MHz 2MB machine and a 40MB hard drive (well, 20MB might
be adequate), you'd have a slow but adequate PC compatible that could run
Linux and other free GNU software -- and those machines are getting real cheap!
I went with the big machine because I want to run heavy-duty Fortran and
other compiler stuff, but so far I'm mostly running kermit.... :-)

Good luck, and thanks for your responses!

        tq vm, (burley)

Newsgroups: gnu.utils.bug
From: kagotani@cs.titech.ac.jp (Hiroto Kagotani)
Subject: finger-1.35: ignored `&' in the gecos field
Organization: Department of Computer Science, Tokyo Institute of Technology
Distribution: gnu
Date: Sun, 6 Sep 1992 11:54:48 GMT

version: finger Version 1.35

utmp_to_packets() function extracts fullnames of users from passwd
gecos fields. But it ignores `&' letter, while pw_real_name() function
in util.c doesn't.  The following fix makes utmp_to_packets() to use
the pw_real_name() as a subroutine.  The fix works fine in my site.
--
Hiroto Kagotani <kagotani@cs.titech.ac.jp>

--- lib/os.c.orig	Sat Aug 29 06:04:23 1992
+++ lib/os.c	Sun Sep  6 20:37:27 1992
@@ -241,7 +241,7 @@
 	uid = -1;
 	if (passwd_entry && passwd_entry->pw_gecos)
 	  {
-	    register char *t = passwd_entry->pw_gecos;
+	    char *pw_real_name ();
 	    register int j;
 	    char device_name[50];
 	    struct stat finfo;
@@ -335,13 +335,7 @@
 #endif /* _AIX */
 	      }
 
-	    for (j = 0; t[j] && t[j] != ';' && t[j] != ','; j++);
-	    t[j] = '\0';
-
-	    if (*t)
-	      strcpy (result[i]->real_name, t);
-	    else
-	      strcpy (result[i]->real_name, "");
+	    strcpy (result[i]->real_name, pw_real_name (passwd_entry));
       	  }
 	else
 	  {

Newsgroups: gnu.utils.bug
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Bug in  make 3.62
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 01:06:55 GMT

	I have found a bug in make-3.62, which can result in make crashing
with a segmentation fault.  I am enclosing a patch which fixes this.

	Basically the problem is that if we do not check to make sure that
p[l] is within the actual string we are looking at, then p[l] could have any
value.  I ran across a situation under linux where the string was "CC=cc",
and when we got to the test for word1eq ("ifndef", 6), it looked at the
character which was just after the terminating null in "CC=cc", and this number
turned out to be negative.  When it got to the isblank test, it was looking
in the ctype array with a negative index, and as it turned out, this
led to a segmentation fault.

	To fix this, I simply added a test to make sure that (strlen(p) > l)

	It might also be a good idea to change the data type of p and p2 to be
unsigned, as well.

-Eric

*** read.c.~1~	Thu Sep 10 23:46:15 1992
--- read.c	Sat Sep 12 21:35:36 1992
***************
*** 331,338 ****
        if (*p == '\0' && lb.buffer[0] != '\t')
  	continue;

! #define	word1eq(s, l) 	((p[l] == '\0' || isblank (p[l])) && \
! 			 !strncmp (s, p, l))
        if (word1eq ("ifdef", 5) || word1eq ("ifndef", 6)
  	  || word1eq ("ifeq", 4) || word1eq ("ifneq", 5)
  	  || word1eq ("else", 4) || word1eq ("endif", 5))
--- 331,339 ----
        if (*p == '\0' && lb.buffer[0] != '\t')
  	continue;

! #define	word1eq(s, l) 	(strlen(p) > l &&
! 			 ((p[l] == '\0' || isblank (p[l])) && \
! 			  !strncmp (s, p, l)))
        if (word1eq ("ifdef", 5) || word1eq ("ifndef", 6)
  	  || word1eq ("ifeq", 4) || word1eq ("ifneq", 5)
  	  || word1eq ("else", 4) || word1eq ("endif", 5))

Newsgroups: gnu.utils.bug
From: kagotani@cs.titech.ac.jp (Hiroto Kagotani)
Subject: finger-1.35: typo around login name comparison
Organization: Department of Computer Science, Tokyo Institute of Technology
Distribution: gnu
Date: Sun, 6 Sep 1992 16:04:29 GMT

version: finger Version 1.35

There is an obvious typo.  The fix follows.  Equality of two strings
must be checked by `!strncmp()', and `!sizeof()' is nonsense.
--
Hiroto Kagotani <kagotani@cs.titech.ac.jp>

--- lib/os.c.orig	Sat Aug 29 06:04:23 1992
+++ lib/os.c	Mon Sep  7 00:40:27 1992
@@ -429,8 +429,8 @@
 	  /* If the same person is logged in more than once, we are
 	     interested in the least idle time.  However, we want to
 	     keep track of the console user. */
-	  if (unique && strncmp (result[i]->ut_name, UT (entry, ut_name),
-				 !sizeof ( UT(entry, ut_name))))
+	  if (unique && !strncmp (result[i]->ut_name, UT (entry, ut_name),
+				 sizeof ( UT(entry, ut_name))))
 	    {
 	      if (idle_less_than (&UTSTRUCT (entry), result[i]))
 		bcopy (&UTSTRUCT (entry), result[i], sizeof (UTSTRUCT (entry)));

Newsgroups: gnu.utils.bug
From: arj@cam-orl.co.UK (Andy Jackson)
Subject: Gas questions
Organization: Olivetti Research Ltd, Cambridge, England.
Distribution: gnu
Date: Thu, 10 Sep 1992 09:15:43 GMT

What is the most recent version of gas with the 29K support ?. I have a
version from AMD tagged as pre-alpha 1.92.1. Is this the most up to date
copy ?. In addition, has anybody added macro support to gas ?. Lastly,
who (if anybody) is the maintainer of gas ?.

	Thanks,
			Andy..

-- 
--------------------------------------------------------------------------
  Andy Jackson - arj@cam-orl.co.uk - phone 0223-343308 - fax 0223-323542
    Olivetti Research, 24a Trumpington Street, Cambridge, UK, CB2 1QA
--------------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: tar-1.11 on Sun4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 16:05:38 GMT

To build tar-1.11 on Sun Sparc (Sun OS 4.1.1), it is necessary to include
<sys/time.h> in getdate.y . Otherwise:

gcc -O -traditional -g  -target sun4 -c -o getdate.o y.tab.c
getdate.y: In function `get_date':
getdate.y:858: storage size of `tv' isn't known    /* struct timeval */
getdate.y:859: storage size of `tz' isn't known    /* struct timezone */
*** Error code 1

Here are the relevant parts of config.status:

PROGS='tar rmt'
CC='gcc -O -traditional'
CPP='${CC-cc} -E'
INSTALL='/bin/install -c'
INSTALL_PROGRAM='$(INSTALL)'
INSTALL_DATA='$(INSTALL) -m 644'
YACC='bison -y'
RTAPELIB='rtapelib.o'
DEF_AR_FILE='/dev/rmt8'
ALLOCA=''
MALLOC='malloc.o'
LIBS=''
srcdir='.'
DEFS=' -DDIRENT=1 -DHAVE_SYS_MTIO_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRSTR=1 -DHAVE_VALLOC=1 -DHAVE_MKDIR=1 -DHAVE_MKNOD=1 -DHAVE_RENAME=1 -DHAVE_FTRUNCATE=1 -DHAVE_FTIME=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DBSD42=1'
prefix=''
exec_prefix=''
prsub=''

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.utils.bug
From: ezk@chestnut.cs.columbia.edu (Erez "HWank1" Zadok)
Subject: GNU Finger 1.35 possible memory leak
Organization: Gnus Not Usenet
Distribution: gnu
Date: Sat, 12 Sep 1992 18:06:54 GMT

In file lib/text-finger.c, function local_finger(), line 81, you "return;"
without performing "free_array(packets);", which you do at the end of the
function.

Erez.
-----
A wank's morning starts one machine   | Arpa:   ezk@cs.columbia.edu
clock cycle after midnight.           | Usenet: ...!rutgers!columbia!cs!ezk
 -HebrewWank #1 (US meaning, not UK!) | Bitnet: erzus@cuvmb.BITNET

Xref: sparky gnu.utils.bug:1611 comp.os.msdos.programmer:9386
From: sjg@zen.void.oz.au (Simon J. Gerraty)
Newsgroups: gnu.utils.bug,comp.os.msdos.programmer
Subject: Re: MS-DOS Version of diff Exhausts Memory
Date: 15 Sep 92 10:24:36 GMT
Followup-To: gnu.utils.bug,comp.os.msdos.programmer
Organization: zen programming...
Apparently-To: bug-gnu-utils@prep.ai.mit.edu

In <1992Sep3.155835.10175@midway.uchicago.edu> pynq@midway.uchicago.edu (George Jetson) writes:
>In article <87kn3yb.westes@netcom.com> westes@netcom.com (Will Estes) writes:
>>Using the MS-DOS version of diff 1.15, I occasionally get an error
>>message reporting that memory has been exhausted (this on a machine that
>>has 15 megs of extended memory).  Do other users of the
>>MS-DOS version get the same error?  Can someone point me to an ftp site

>This tells us nothing about which specific version of diff you are using.
>Who is it from? Who compiled it? Which compiler? etc.

I'd guess GNU diff-1.15 and he compiled it himself.

Anyway, I noted a similar problem when I was forced to port GNU
egrep to MS-DOS.  I don't have the sources or my diffs on-line
so this is a touch vague.  The basic problem was that once the
initial small (16k?) buffer was outgrown, a call to realloc is
made with size set by (1 << 16) which is 64k, but guess what
happens on MS-DOS with its 16bit int's?  Yep, realloc is called
with a size of 0, causing everyone to think that there is no
memory left.

I can't recall whether I made it (1 << 15) or ((1 << 16) - 1)
(if being compiled on MSDOS) anyway that made the problem
dissappear.

Look for calls to {m,re,xm,xre}alloc and check the sizes being
used keeping in mind that you only have 16bits.

-- 
Simon J. Gerraty        <sjg@zen.void.oz.au>

#include <disclaimer>   /* imagine something _very_ witty here */
Newsgroups: gnu.utils.bug
From: jtc@gain.COM (J.T. Conklin)
Subject: tar-1.11 and HPUX 8.07
Reply-To: jtc@gain.com
Organization: GAIN Technology Inc., Palo Alto, CA
Distribution: gnu
Date: Thu, 10 Sep 1992 11:54:34 GMT

Fixed in patch:
1. compiler doesn't handle files where '#' of a preprocessor directive is
   not the first character of a line.

Not fixed in patch:
1. linking with -lPW for alloca causes link error with unresolved external
   ``Error''.  Using alloca.c works.

*** OLD/buffer.c	Thu Sep 10 18:24:40 1992
--- buffer.c	Thu Sep 10 18:24:25 1992
***************
*** 1337,1345 ****
  			    break;

  		    case '!':
!     #ifdef __MSDOS__
  			    spawnl(P_WAIT,getenv("COMSPEC"),"-",0);
!     #else
  				    /* JF this needs work! */
  			    switch(fork()) {
  			    case -1:
--- 1337,1345 ----
  			    break;

  		    case '!':
! #ifdef __MSDOS__
  			    spawnl(P_WAIT,getenv("COMSPEC"),"-",0);
! #else
  				    /* JF this needs work! */
  			    switch(fork()) {
  			    case -1:
***************
*** 1355,1361 ****
  				    wait(0);
  				    break;
  			    }
!     #endif
  			    break;
  		  }
  		  }
--- 1355,1361 ----
  				    wait(0);
  				    break;
  			    }
! #endif
  			    break;
  		  }
  		  }
*** OLD/extract.c	Thu Sep 10 18:25:11 1992
--- extract.c	Thu Sep 10 18:25:53 1992
***************
*** 293,299 ****
  			 fd = 1;
  			 goto extract_file;
  		 }
!  #ifdef O_CTG
  		 /*
  		  * Contiguous files (on the Masscomp) have to specify
  		  * the size in the open call that creates them.
--- 293,299 ----
  			 fd = 1;
  			 goto extract_file;
  		 }
! #ifdef O_CTG
  		 /*
  		  * Contiguous files (on the Masscomp) have to specify
  		  * the size in the open call that creates them.
***************
*** 304,312 ****
  				   openflag | O_CTG,
  				   hstat.st_mode, hstat.st_size);
  		 else
!  #endif
  		 {
!  #ifdef NO_OPEN3
  			 /*
  			  * On raw V7 we won't let them specify -k (f_keep), but
  			  * we just bull ahead and create the files.
--- 304,312 ----
  				   openflag | O_CTG,
  				   hstat.st_mode, hstat.st_size);
  		 else
! #endif
  		 {
! #ifdef NO_OPEN3
  			 /*
  			  * On raw V7 we won't let them specify -k (f_keep), but
  			  * we just bull ahead and create the files.
***************
*** 315,327 ****
  				     ? longname
  				     : head->header.name) + skipcrud,
  				    hstat.st_mode);
!  #else
  			 /*
  			  * With 3-arg open(), we can do this up right.
  			  */
  			 fd = open(skipcrud + current_file_name,
  				   openflag, hstat.st_mode);
!  #endif
  		 }

  		 if (fd < 0) {
--- 315,327 ----
  				     ? longname
  				     : head->header.name) + skipcrud,
  				    hstat.st_mode);
! #else
  			 /*
  			  * With 3-arg open(), we can do this up right.
  			  */
  			 fd = open(skipcrud + current_file_name,
  				   openflag, hstat.st_mode);
! #endif
  		 }

  		 if (fd < 0) {

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: tar 1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 14:39:20 GMT

   Resent-Date: Fri, 11 Sep 92 12:25:45 MDT
   Date: Fri, 11 Sep 92 12:25:45 MDT
   From: Egan F. Ford <egan@upl.com>
   Sender: gnulists@ai.mit.edu
   X-Mailer: ELM [version 2.3 PL11]
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   I have an SCO 3.2.4 with 3.2.4 Dev and gcc 2.2.2.  After ./configure
   --prefix=/usr/gnu and setting in the Makefile -traditional -D_NO_PROTOTYPE 
   -D_KR -D_SVID I got the thing to start to compile until gnu.c then I get 
   the error:

You should not have used -traditional, or the other options.
Configure should correctly figure out the options to use, or it has a
bug.  You should never need to edit the Makefile produced by GNU
programs which come with configure.

	-mib


Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Configure [was: tar 1.11]
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 11:42:26 GMT

   Configure should correctly figure out the options to use, or it has
   a bug.  You should never need to edit the Makefile produced by GNU
   programs which come with configure.

These statements look quite strong to me, too strong in fact!  I would
certainly never expect `configure' to discover all peculiarities and
strangenesses of all systems and installations.  I'm just speaking for
Autoconf, which I know better.  There is a certain amount of ugliness
beyond which GNU configurators should refuse to go.  In these cases,
we should rather let users correct their own system installation,
fiddle with config.status (thus, indirectly editing the Makefile), or
even, in the worst cases, playing with the generated Makefile itself.

As of now, Autoconf generates configure scripts which behave fairly
well for almost all machines I work on.  This is a Good Thing, and am
quite satisfied with it.  This is *far* better than doing all the
configuring job by hand, as was done before.  It is a very helping
tool.  But it does not pretend to do everything everywhere and anyhow.
I feel David Mackenzie has the right attitude on this.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: ramey@ra.CSc.ti.COM (Joe Ramey)
Subject: gnu tar 1.11: cvf dumps core
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 00:43:17 GMT

tar cvf - . > /dev/null dumps core.  This is with GNU tar 1.11 on a
Sun4 running 4.1.1.

A gdb stack trace:

#0  quote_copy_string (string=0x0) at port.c:784
#1  0xe304 in print_header () at list.c:536
#2  0x6f7c in finish_header (header=0x24000) at create.c:1276
#3  0x6474 in dump_file (p=0xf7fffbaf ".", curdev=-1, toplevel=1)
    at create.c:683
#4  0x57f0 in create_archive () at create.c:178
#5  0x27b8 in main (argc=4, argv=0xf7fffb34) at tar.c:232

Looks like print_header expects current_file_name to be set to
something.

Newsgroups: gnu.utils.bug
From: ian@airs.COM (Ian Lance Taylor)
Subject: Re: GNU `wc -c' optimization
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 21:01:55 GMT

gumby@cygnus.com (David V. Henkel-Wallace) writes:

>   From: pinard@icule.UUCP (Francois Pinard)

>   Using GNU textutils 1.3, I noticed that `wc -c FILE' or `wc -c *'
>   physically reads the file(s).  Would not it be better to just stat the
>   file(s) and produce the output quickly in those cases?

>Until wc handles wide characters...

POSIX.2 defines wc -c to output a number of bytes.  I doubt that will
change without adding another option.

Whether the optimization is worth putting in depends on how often
people use wc -c, I guess.
-- 
Ian Lance Taylor                ian@airs.com                 uunet!airs!ian
First person to identify this quote wins a free e-mail message:
``He caught the lady in this way: so when the lady was running away for her
  life, he hastily ran to her front and stopped her as a log of wood.''

Newsgroups: gnu.utils.bug
From: gumby@cygnus.com (David V. Henkel-Wallace)
Subject: GNU `wc -c' optimization
Organization: Cygnus Support, Palo Alto, California
Distribution: gnu
Date: Mon, 7 Sep 1992 10:40:16 GMT

   Date: Sat, 5 Sep 1992 13:46:09 GMT
   From: pinard@icule.UUCP (Francois Pinard)

   Using GNU textutils 1.3, I noticed that `wc -c FILE' or `wc -c *'
   physically reads the file(s).  Would not it be better to just stat the
   file(s) and produce the output quickly in those cases?

Until wc handles wide characters...

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Other GNU tar 1.11 problems
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 16:24:53 GMT

Using GNU tar 1.11, compiled with GNU C 1.40 under COFF encapsulation
on a 386/ix 2.0.2 (still waiting for Hurd :-), and with an archive
made through GNU tar 1.10 by:

	tar cvV "GNU grep 1.6" grep.tar.Z

I get:

----->
/usr0/tmp) tar xv
GNU grep 1.6
Reading GNU grep 1.6
grep.tar.Z
tar: couldn't change access and modification times of [lines of garbage]
tar: cannot change mode of file [lines of garbage]
/usr0/tmp) 
-----<

where [lines of garbage] are many lines of random codes ending,
probably by luck, with `...& to 416 : No such file or directory'.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Subject: Problems with GNU tar 1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 10:48:27 GMT

   Resent-Date: Mon, 14 Sep 1992 15:38:51 GMT
   Newsgroups: gnu.utils.bug
Path: rkl
   From: R.K.Lloyd@csc.liv.ac.uk (Richard Lloyd)
   Sender: gnulists@ai.mit.edu
   Date: Mon, 14 Sep 1992 15:38:51 GMT
   Nntp-Posting-Host: dee.csc.liv.ac.uk
   Apparently-To: gnu-utils-bug@uk.ac.uknet
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   I got GNU tar 1.11 compiled on our HP 9000/720 machines running HP-UX 8.07, but not after some struggles:

   [Note that if you set CFLAGS to any optimisation level (e.g. +O3), create.c
   generates some very "dangerous" compiler warnings about optimisation. It's a
   message about "differences between two arrays won't be properly optimised"]

Not surprising.  Tar wouldn't lint well...

   Source code changes:

   buffer.c and extract.c had some cpp directives indented by one column, which
   isn't right.

   SERIOUS BUG IN list.c:

   The "v" option of "tar cvf" was only printing blank lines for the filenames !
   After comparing 1.10 and 1.11, it was clear that a new variable had been
   substituted in list.c (current_file_name) that wasn't properly set up. I
   changed it back to the old 1.10 variable (although it was now arch_name rather than name) and tar cvf correctly printed the filenames out.

   A modified version of tar 1.11 for HP-UX machines is now available from our
   anonymous FTP site, ftp.csc.liv.ac.uk (138.253.42.172).

Nobody should need this; please don't pick it up.  All the bugs
mentioned in this article have been fixed, and an intermediate release
will be made today including them and some other bugs.  I'm not able
to fix bugs in multiple divergent distributions.  The standard
distribution should run on HP-UX just fine.

	-mib




Newsgroups: gnu.utils.bug
From: burley@cygnus.com (Craig Burley)
Subject: index-1.6 stdin bug? & question
Reply-To: burley@gnu.ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 20:39:28 GMT

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)

Newsgroups: gnu.utils.bug