HDTenEightyP/NetNews huggingface dataset:
From: rdb@cocamrd.mel.cocam.oz.AU (Rodney Brown)
Subject: Suggested patch for gdb-4.6 compilation on SCO Unix 3.2.4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Sep 1992 02:20:36 GMT

This is hardly a bug but more a suggestion to escape SCO's agressive
POSIX compliance where defines not mentioned in the the standard are
excluded from the [A-Z].* namespace.

uname -a 
cocamrd cocamrd 3.2 2 i386	(SCO Unix 3.2.4)
gcc -v
Reading specs from /usr/local/lib/gcc-lib/i386-sco-sco3.2v4_/2.2.2/specs
gcc version 2.2.2

(specs)
*cpp:
-D__i386 -D_M_I386 -D_M_I86 -D_M_I86SM -D_M_SDATA -D_M_STEXT \
-D__unix -D_M_UNIX -D_M_XENIX   -D_M_SYS5 -D_M_SYSV -D_M_SYSV -D_M_SYS3 \
-D_M_SYSIII   -D_M_COFF -D_M_BITFIELDS -D_M_WORDSWAP \
%{scoxpg3:-D_XOPEN_SOURCE -D_STRICT_NAMES} \
%{!scoxpg3:%{posix:-D_POSIX_SOURCE -D_STRICT_NAMES}} \
%{!scoxpg3:%{!posix:  %{ansi:-D_STRICT_NAMES}%{!ansi:  -Di386 -DM_I386 \
-DM_I86 -DM_I86SM -DM_SDATA -DM_STEXT   -Dunix -DM_UNIX -DM_XENIX   \
-DM_SYS5 -DM_SYSV -D_M_SYSV -DM_SYS3 -DM_SYSIII   -DM_COFF -DM_BITFIELDS \
-DM_WORDSWAP   %{scointl:-D_M_INTERNAT -DM_INTERNAT} -D__STDC__=0}}}


*endfile:
crtend.o%s   %{scoxpg3:crtnX.o%s}   %{!scoxpg3:   %{posix:crtnP.o%s} \
%{!posix:    %{ansi:crtnA.o%s}     %{!ansi:crtn.o%s}}}

*startfile:
%{scoxpg3:%{p:mcrt1X.o%s}%{!p:crt1X.o%s}}   %{!scoxpg3: \
%{posix:%{p:mcrt1P.o%s}%{!p:crt1P.o%s}}    %{!posix: \
%{ansi:%{p:mcrt1A.o%s}%{!p:crt1A.o%s}}  \
%{!ansi:%{pg:gcrt1.o%s}%{!pg:%{p:mcrt1.o%s}%{!p:crt1.o%s}}}}}   crtbegin.o%s

GDB 4.6, Copyright 1992 Free Software Foundation, Inc.

(Makefile)
# This file was generated automatically by configure.  Do not edit.
VPATH = .
links =  xm.h tm.h
host_alias = sco
host_cpu = i386
host_vendor = unknown
host_os = scosysv322
target_alias = sco
target_cpu = i386
target_vendor = unknown
target_os = scosysv322
target_makefile_frag = config/i386v32.mt
host_makefile_frag = config/i386sco.mh
ALL=all.internal

*** gdb-4.6__gdb__source.c	Sat Sep 12 17:39:45 1992
--- source.c	Mon Aug 31 21:08:40 1992
***************
*** 32,37 ****
--- 32,40 ----
  #include <string.h>
  #include <sys/param.h>
  #include <sys/stat.h>
+ #ifndef	S_ISDIR
+ #define S_ISDIR(m)	(((m) & S_IFMT) == S_IFDIR)
+ #endif
  #include <fcntl.h>
  #include "gdbcore.h"
  #include "regex.h"
***************
*** 351,357 ****
        if (name[0] != '$') {
  	if (stat (name, &st) < 0)
  	  perror_with_name (name);
! 	if ((st.st_mode & S_IFMT) != S_IFDIR)
  	  error ("%s is not a directory.", name);
        }
  
--- 354,360 ----
        if (name[0] != '$') {
  	if (stat (name, &st) < 0)
  	  perror_with_name (name);
! 	if (S_ISDIR(st.st_mode))
  	  error ("%s is not a directory.", name);
        }
  
-- 
Rodney Brown,  Co-Cam Computer Group,  ACSNet: rdb@mel.cocam.oz.au

Newsgroups: gnu.gdb.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: gdb coredumps if bad object file
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu
Date: Tue, 8 Sep 1992 15:53:16 GMT

In article <9209042155.AA28088@_la.tce.com> pierre@la.tce.com writes:
>I recommend testing for (m) != NULL in the ALL_MSYMBOLS macro
>in objfiles.h (gdb 4.5 at least). All other macros in objefiles.h
>are safe except this one.
>
>It happened to me that I had a bad object file and that an error
>occured in reading in dbx_symfile_init() and then gdb would core dump
>because objfile -> msymbol is NULL.

In 4.6, ALL_MSYMBOLS does test (objfile)->msymbols before calling
ALL_OBJFILE_MSYBMOLS, which actually does the iteration, so that the
remaining object files are processed:


/* Traverse all minimal symbols in one objfile.  */

#define	ALL_OBJFILE_MSYMBOLS(objfile, m) \
    for ((m) = (objfile) -> msymbols; (m)->name != NULL; (m)++)


/* Traverse all minimal symbols in all objfiles.  */

#define	ALL_MSYMBOLS(objfile, m) \
  ALL_OBJFILES (objfile)	 \
    if ((objfile)->msymbols)	 \
      ALL_OBJFILE_MSYMBOLS (objfile, m)


>So, it is safer to replace ALL_MSYMBOLS by the following :
>
>#define	ALL_MSYMBOLS(objfile, m) \
>  ALL_OBJFILES (objfile)	 \
>    for ((m) = (objfile) -> msymbols; ((m) != NULL) && ((m)->name != NULL); (m)++)

I think the 4.6 implementation is cleaner.

>Maybe an additional fix would be to remove this object file from the
>list.

Yes, but that would be nontrivial :-)

It might also be useful to notify the user when a bad object file is
found.  I'm not familiar with gdb's internals, so I can't provide a
complete fix, but here's what I have in mind:

#define	ALL_MSYMBOLS(objfile, m) \
  ALL_OBJFILES (objfile)	 \
    if (!(objfile)->msymbols)	 \
      ; /* emit warning */ \
    else \
      ALL_OBJFILE_MSYMBOLS (objfile, m)
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.gdb.bug
From: malcolmp@hydra.maths.unsw.edu.au (malcolmp)
Subject: In what state is the Apollo port?
Organization: School of Mathematics, UNSW, Sydney, Australia
Distribution: gnu
Date: Tue, 15 Sep 1992 05:44:43 GMT

	When I picked up gdb-4.6 the other day I noticed that configure had an
entry for Apollos.  This is dispite the Apollo documentation in gcc-2.2.2
saying that a port of bfd to the Apollos would be greatly appreciated.  In
what state is the Apollo port?  Trying to build gdb on an Apollo produces very
mixed results so I'm surprised that Apollos get mentioned in the first place.
As an exercise in learning low level Apollo programming I might try porting it
myself but I'd like to know if I'm going to duplicate any existing work before
I start.

	Thanks.
--
		Malcolm Purvis (malcolmp@hydra.maths.unsw.edu.au)
		School of Mathematics, UNSW, Sydney, Australia.

Newsgroups: gnu.gdb.bug
From: martens@gdss.commerce.ubc.ca (Clarence Martens)
Subject: gdb 4.6 and the NeXT computer
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 09:36:07 GMT

Beginning an install of gdb version 4.6 on a NeXT computer gave the
following message:
	*** Gdb does not support host m68k-next-bsd
The argument I gave to the configure script was "next". I also tried
giving the configure script the value "m68k-next-mach", but that didn't
work either. 

Does gdb work on the NeXT? The version of gdb included with the NeXT's 
system software is too old for me. Is there any way to make it work?

Clarence Martens

Newsgroups: gnu.gdb.bug
From: gert@greenie.ucrc.SUb.ORG
Subject: core dumps in gdb 4.6 on SCO Sys V
Reply-To: gert.doering@physik.tu-muenchen.de, gert.doering@ap.mchp.sni.de
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Sep 1992 16:17:12 GMT

Hi, 

I just compiled GDB 4.6 on a SCO Unix V, Rel. 3.2.1 machine. When debugging
a "hello world" program, everything works fine, but when (heavy testing) I
try to debug gdb with itself, it crashes:
(gdb/gdb is the 4.6 version, to produce stack trace, gdb 4.4 is used)
(configuration is "i386sco", -DFASCIST_FDOPEN)
------ $ gdb44 gdb/gdb ---------------
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) run
Starting program: /u/softadm/gdb-4.6/gdb/gdb 
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.6, Copyright 1992 Free Software Foundation, Inc.
(gdb) file gdb/gdb
Reading symbols from gdb/gdb...
Program received signal 10, Bus error
mrealloc_check (md=0x0, ptr=0x531008, size=5120) at mmcheck.c:131
mmcheck.c:131: No such file or directory.
(gdb) where
#0  mrealloc_check (md=0x0, ptr=0x531008, size=5120) at mmcheck.c:131
#1  0x8f1e2 in mrealloc (md=0x0, ptr=0x531008, size=5120) at mrealloc.c:57
#2  0x291f5 in xmrealloc (md=0x424d08, ptr=0x10d, size=5120) at utils.c:568
#3  0x29238 in xrealloc (ptr=0x531008, size=5120) at utils.c:598
#4  0x47b9d in coff_lookup_type (index=642) at coffread.c:324
#5  0x47be8 in coff_alloc_type (index=642) at coffread.c:341
#6  0x49b0c in coff_read_struct_type (index=642, length=4, lastsym=648)
    at coffread.c:1995
#7  0x49a8c in decode_base_type (cs=0x424d08, c_type=9, aux=0x0)
    at coffread.c:1929
#8  0x498e3 in decode_type (cs=0x7ffffd04, c_type=9, aux=0x41ed0c)
    at coffread.c:1826
#9  0x4947f in process_coff_symbol (cs=0x7ffffd04, aux=0x41ed0c, 
    objfile=0x43ef08) at coffread.c:1614
#10 0x48cba in read_coff_symtab (symtab_offset=998606, nsyms=153166, 
    objfile=0x43ef08) at coffread.c:1167
#11 0x483a9 in coff_symfile_read (objfile=0x43ef08, section_offsets=0x409fd8, 
    mainline=1) at coffread.c:832
#12 0x1f937 in syms_from_objfile (objfile=0x43ef08, addr=0, mainline=1, 
    verbo=1) at symfile.c:450
#13 0x1fb56 in symbol_file_add (name=0x42c308 "gdb/gdb", from_tty=1, addr=0, 
    mainline=1, mapped=0, readnow=0) at symfile.c:581
#14 0x1fdb5 in symbol_file_command (args=0x42b14c "", from_tty=1)
    at symfile.c:681
#15 0x31a04 in file_command (arg=0x42900d "gdb/gdb", from_tty=1) at exec.c:198
#16 0x1513 in execute_command (p=0x42900d "gdb/gdb", from_tty=1) at main.c:915
#17 0x1674 in command_loop () at main.c:976
#18 0x1384 in main (argc=1, argv=0x7ffffef8) at main.c:853
(gdb) quit
The program is running.  Quit anyway? (y or n) 
----------------------
thanx,

gert doering

Newsgroups: gnu.gdb.bug
From: alexb@spock.retix.com (Alex Berg)
Subject: gdb on RS-6000
Organization: Retix, Santa Monica
Distribution: gnu
Date: Fri, 11 Sep 1992 18:50:03 GMT

Hi GDB people,

Please Help !!!!!

I am trying to port gdb (versions 4.5-4.6) on RS-6000, running AIX
3.2.  Portation goes thru smoothly - I can compile, link, and invoke
gdb (either version).  However, when I load an executable (compiled
with -g options), and tell gdb to run (hit 'r'), the whole machine
crashes and burns.

If anyone has any infomation on this, please e-mail or post.
Thank you in advance.

--

Alex.


 +------------------------+-------------------------------------------------+
 | Alexander Berg         |                                                 |
 | Retix                  |  President Bush:                                |
 | 2401 Colorado Ave.     |                                                 |
 | Santa Monica, CA 90404 |     Read my MIPS, No new VAXES !!!              |
 | (310) 828-3400  x239   |                                                 |
 | alex-berg@retix.com    |                                                 |
 +------------------------+-------------------------------------------------+
-- 

Alex.



Newsgroups: gnu.gdb.bug
From: gnu@cygnus.com
Subject: Re: cross-debugging core files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 04:06:33 GMT

> The way things work right now, a *host-dependent* function gets called
> to e.g., scan the core file for register contents. I don't see why
> this isn't done through target-dependent code.
> BFD already does the right thing (it reads a FooBar core with the
> FooBar routines) so it seems to me that all the fetch_core_registers
> functions need to me moved out of the xdep files and into the tdep
> files in order to get this to work, but not much more.

If core files were as well documented and as well magic-numbered as
executable files, this would be the right thing.  Most core files are
not distinguishable from files full of binary garbage, though.  (They
tend to contain a lot of binary garbage, with a "u area" dump stuck on
the end.)  So doing BFD-style automatic recognition on all core files
is not going to work.

Some vendors have made more recognizable core file formats (Sun for
example), and BFD can recognize a Sun3 or Sun4 core file (though Sun
didn't really design it with this in mind -- see the BFD sources).
The main problem here is that the include files needed to define most
of these core files only exist on the machine that generates the core
file.  (Most core files contain the "u area" from the kernel, which
itself takes five or ten system-specific include files to describe.)
We could try to produce a new include file to describe each variant on
core files, but many are only documented in the (copyrighted!) include
files on the vendor's system.

A third problem is that core files (like a.out executables) don't
really give you all the information you need -- like the virtual
memory addresses of the various sections.  The assumption is that you
must be running on a FooStation so you must know that all FooStation
executables start at 0x2000 and all FooStation stacks end at 0xF7FFFFFF.

In SVR4, core files are kept in ELF format, which is definitely a step
forward.  Of course, they defined two different kinds of ELF files
(the "linking view" and the "section view" or something like that), so
it's not completely simple.  But the right information is there, it's
well flagged and documented, and GDB should someday be able to support
cross-debugging with ELF core files.

We are currently working on teaching GDB to configure itself
differently for native debugging versus cross debugging.  This should
make it easier to support cross-core-debugging on machines with
reasonable core file formats.

	John Gilmore
	GDB maintainer

Newsgroups: gnu.gdb.bug
From: alexb@mproj.retix.com (Alexander Berg)
Subject: Please HELP !!!
Organization: Gnus Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 09:32:26 GMT

I am trying to port gdb (versions 4.5-4.6) on RS-6000, running AIX
3.2.  Portation goes thru smoothly - I can compile, link, and invoke
gdb (either version).  However, when I load an executable (compiled
with -g options), and tell gdb to run (hit 'r'), the whole machine
crashes and burns.

Thank you in advance for any information.


Alex.


 +------------------------+-------------------------------------------------+
 | Alexander Berg         |                                                 |
 | Retix                  |  If trees could scream, would we be so cavalier |
 | 2401 Colorado Ave.     |  about cutting them down? We might, if they     | 
 | Santa Monica, CA 90404 |  screamed all the time, for no good reason.     |
 | (310) 828-3400  x239   |                  Deep Thoughts By Jack Handey   |
 | alex-berg@retix.com    |                                                 |
 +------------------------+-------------------------------------------------+

Newsgroups: gnu.gdb.bug
From: dfavor@logan.tivoli.com (David Favor)
Subject: gdb 4.6 interrupt problem?
Keywords: gdb,interrupt,problem,signal,gnu,debugger
Organization: TIVOLI Systems, Inc.
Distribution: gnu
Date: Wed, 9 Sep 1992 14:56:01 GMT

I'm using gdb-4.6 (with no patches applied) under SunOS 4.1.2
for the first time (this off course may be the problem). when
I continue (cont) a program under gdb control then type ^C control
is never returned to gdb. 'info signal 2' says...

(gdb) info signal 2
Signal          Stop    Print   Pass to program Description
SIGINT (2)      Yes     Yes     No              Interrupt

pressing ^C displays '^C', however, gdb continues instead of
returning control to the command line. what am I missing here?
how can I ^C during program execution to interact with gdb?

Newsgroups: gnu.utils.bug
From: yasu@ll.mit.edu (Alan Yasutovich)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 10:28:33 GMT

	I am trying to build find on an HP 730.  Below is the output.

	Can you tell me how to fix it so it will build?
	One of the problems is libfind.a,


	Thanks

	Alan





for dir in lib find xargs locate man; do echo making all in $dir; cd $dir; make bindir='/usr/local/gnubin' libdir='/usr/local/lib/locate' datadir='/usr/local/lib/locate' mandir='/usr/local/man/man1' manext='1' FCODES='/usr/local/lib/locate/find.codes' INSTALL='install -c' INSTALLDATA='install -c -m644' AR='ar' RANLIB='ranlib' CFLAGS='-g -I. -I../lib -I./lib -DDIRENT -DFS_MNTENT -DSTDC_HEADERS -DPOSIX' LDFLAGS='-g' LIBS='' CC='gcc -O' all; cd ..; done
making all in lib
gcc -O -g -I. -I../lib -I./lib -DDIRENT -DFS_MNTENT -DSTDC_HEADERS -DPOSIX   -c error.c -o error.o
cc1: warning: `-g' option not supported on this version of GCC
error.c: In function `error':
error.c:87: incompatible type for argument 3 of `vfprintf'
make[1]: *** [error.o] Error 1
making all in find
make[1]: *** No way to make target `../lib/libfind.a'.  Stop.
making all in xargs
gcc -O -g -I. -I../lib -I./lib -DDIRENT -DFS_MNTENT -DSTDC_HEADERS -DPOSIX   -c xargs.c -o xargs.o
cc1: warning: `-g' option not supported on this version of GCC
In file included from /usr/include/unistd.h:11, from xargs.c:120:
/usr/include/sys/unistd.h:225: conflicting types for `getopt'
../lib/getopt.h:91: previous declaration of `getopt'
make[1]: *** [xargs.o] Error 1
making all in locate
make[1]: *** No way to make target `../lib/libfind.a'.  Stop.
making all in man
make[1]: Nothing to be done for `all'.

Newsgroups: gnu.utils.bug
From: zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga)
Subject: Bad call to setvbuf in make 3.62
Reply-To: zuazaga@ucunix.san.uc.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 10:23:25 GMT

Sorry if this one's been reported before, but I looked in
gnu.util.bugs and didn't see it mentioned.

main.c has a call to setvbuf with args 2 and 3 swapped.
-- 
Humberto Ortiz-Zuazaga                            zuazaga@ucunix.san.uc.edu
Dept. of Physiology & Biophysics                   University of Cincinnati

Newsgroups: gnu.utils.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: GNU tar header checksum bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 19:55:26 GMT

This bug report is for GNU tar versions 1.10 and 1.11.

Different versions of tar seem to compute header checksums differently.  I
suspect that the original tar code added up a bunch of "char" values, which
were unsigned on the PDP-11 and that the code was never changed when signed
chars were introduced.  The following patch causes GNU tar to be a little more
forgiving when it tries to read tar archives created with /bin/tar on Nexts,
Suns, and others.


*** list.c.~1~	Tue Sep  8 16:22:38 1992
--- list.c	Thu Sep 10 15:47:56 1992
***************
*** 289,295 ****
  read_header()
  {
  	register int	i;
! 	register long	sum, recsum;
  	register char	*p;
  	register union record *header;
  	long	from_oct();
--- 289,295 ----
  read_header()
  {
  	register int	i;
! 	register long	sum, signed_sum, recsum;
  	register char	*p;
  	register union record *header;
  	long	from_oct();
***************
*** 314,326 ****
  		 * We can't use unsigned char here because of old compilers,
  		 * e.g. V7.
  		 */
  		sum += 0xFF & *p++;
  	}
  
  	/* Adjust checksum to count the "chksum" field as blanks. */
  	for (i = sizeof(header->header.chksum); --i >= 0;)
  		sum -= 0xFF & header->header.chksum[i];
! 	sum += ' '* sizeof header->header.chksum;	
  
  	if (sum == 8*' ') {
  		/*
--- 314,331 ----
  		 * We can't use unsigned char here because of old compilers,
  		 * e.g. V7.
  		 */
+ 	        signed_sum += *p;
  		sum += 0xFF & *p++;
  	}
  
  	/* Adjust checksum to count the "chksum" field as blanks. */
  	for (i = sizeof(header->header.chksum); --i >= 0;)
+ 	{
  		sum -= 0xFF & header->header.chksum[i];
! 		signed_sum -= (char) header->header.chksum[i];
! 	}
! 	sum += ' ' * sizeof header->header.chksum;
! 	signed_sum += ' ' * sizeof header->header.chksum;
  
  	if (sum == 8*' ') {
  		/*
***************
*** 330,336 ****
  		return 2;
  	}
  
! 	if (sum != recsum) 
  	  return 0;
  	
  	/*
--- 335,341 ----
  		return 2;
  	}
  
! 	if (sum != recsum && signed_sum != recsum)
  	  return 0;
  	
  	/*

Xref: sparky gnu.utils.bug:1535 gnu.announce:120
From: karl@claude.cs.umb.edu (Karl Berry)
Newsgroups: gnu.utils.bug,gnu.announce
Subject: regex 0.10 released
Date: 10 Sep 92 01:40:26 GMT
Reply-To: karl@cs.umb.edu
Followup-To: gnu.utils.bug
To: info-gnu-utils@prep.ai.mit.edu

I've released version 0.10 of the GNU regular expression code.
You can get it by anonymous ftp from
   prep.ai.mit.edu [18.71.0.38]:pub/gnu/regex-0.10.tar.Z

And soon from these archive sites around the world (please try them
before prep):

Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
Australia: archie.au:gnu
Europe: ftp.informatik.tu-muenchen.de, src.doc.ic.ac.uk:gnu,
        ftp.funet.fi, nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
        ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
        ftp.diku.dk, ftp.eunet.ch, ftp.funet.fi, archive.eu.net
United States: wuarchive.wustl.edu ftp.cs.widener.edu,
   	       uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
	       ftp.uu.net:packages/gnu

For information on how to order GNU software on tape, check
the file pub/gnu/etc/DISTRIB on prep.ai.mit.edu
or email a request to:	gnu@prep.ai.mit.edu

Important note:

I made one upward-incompatible change, which affects many of the
programs that use regex: the global variable `obscure_syntax' is now
named `re_syntax_options'.  (This was the only public identifier that
did not start with `re_' or `reg'.)  If you like, you can use the
function re_set_syntax instead of assigning directly to this variable.

Here is a summary of the other changes:

* `re_comp's return type is no longer `const', for compatibility with BSD.

* POSIX syntaxes now include as much functionality as possible
  (consistent with the standard).

* Compilation conditionals normalized to what the rest of GNU is
  migrating towards these days.

* Bug fixes involving:
    - Ranges with characters between 0x80 and 0xff, e.g., [\001-\377].
    - `re_compile_fastmap' and the sequence `.*\n'.
    - Intervals with exact counts, e.g., a{5}.

* Changed distribution to use a standard Makefile, install the info
  files, use a configure script, etc.

karl@cs.umb.edu
Newsgroups: gnu.utils.bug
From: tap@src.honeywell.com (Thomas A Peterson)
Subject: finger 1.35: installation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 17:16:54 GMT

hardware - os : sparc-sun-sunos411
Description:

  The script support/install-finger is no longer called when doing a
  'make server' or a 'make client'. The installation instructions say
  nothing about running it manually.

Newsgroups: gnu.utils.bug
From: mju@mudos.ann-arbor.mi.US (Marc Unangst)
Subject: Problem with GNU tar 1.11
Organization: The Programmer's Pit Stop, Ann Arbor MI
Distribution: gnu
Date: Sun, 13 Sep 1992 22:08:28 GMT

There seems to be a bug in GNU tar 1.11's "-v" option.  I am running
on an Intel SVR4 (Esix 4.0.3A) machine, compiling with gcc v2.1.
Aside from commenting out a few

extern char *valloc();

declarations (because they conflicted with the ones in <stdlib.h>), I
have not modified the source.

The problem is that tar prints out a blank line where the filename
should be when -v is given during archive creation (i.e., with the
-c flag).  Using multiple -v's, which should increase the debugging
level, results in a segmentation fault.

I have traced through the code, and it seems that the problem is that
the global current_file_name is not being set correctly when
print_header is called.  print_header attempts to get the current file
name from current_file_name, and so it prints out nothing.  tar
segvios when multiple -v's are given because at the higher debugging
levels, tar tries to do strlen(current_file_name), which results in
strlen being passed a null pointer.

Where and how should current_file_name be set?

-- 
Marc Unangst                | Real men don't use Windows.  Real men use X. 
mju@mudos.ann-arbor.mi.us   | Only a real man would use a GUI where the
                            | shift keys after "Alt" are "Super" and "Hyper."

Newsgroups: gnu.utils.bug