HDTenEightyP/NetNews huggingface dataset:
From: ezk@chestnut.cs.columbia.edu (Erez "HWank1" Zadok)
Subject: GNU finger 1.35 default options
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 8 Sep 1992 03:51:55 GMT

I think you should supply a configuration option that would enable the "-l"
to be the default option, and add a "-s" option.  A lot of people at our
site were too used to it that I had to modify (very simple change) the code
to do that.

Erez Zadok.
---
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
From: kuku@acds.physik.rwth-aachen.de (Christoph Kukulies)
Newsgroups: gnu.utils.bug
Subject: tar-1.11
Date: 14 Sep 92 19:17:31 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Hi,

excuse me when I'm reporting something which may actually not a bug
or a bug already know and repaired - because I may be running an
old version, anyway, here it goes:

Yesterday I had the need to copy remotely from a TK50 drive 
on a remote Ultrix machine to a machine I was sitting on.

I downloaded tar-1.11 from a local ftp site, configured and compiled it -
no problem - I was using Ultrix 4.1.

The tape contained a 2 MB file (genvmunix) and a /usr/src tree. (leading /).
I read the docs and found that gnu-tar seems to rip off the leading
/ anyway which I considered a smart feature.

I gave the command  'tar xvf acds02:/dev/rmt0h' and gnu-tar started
copying. The first big file (genvmunix) got off the tape, then during
copying of the /usr/src tree suddenly everything broke through to stdout
instead of going to the disk. Only a partial copy of the /usr/src tree
was on the disk.

Any idea? Do you need more information? Do you have a newer version?


--Chris
Newsgroups: gnu.utils.bug
From: warmerda@pci.on.CA (Frank Warmerdam)
Subject: tar-1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 17:01:00 GMT

The follow relates a few problems I had building GNU tar under
under IRIX 4.0.1 on a Personal Iris:

While attempting to compile using the default cc with ANSI headers
but to __STDC__ defined or strict type checking I get the following:

cc -c -g  -DMAJOR_IN_SYSMACROS=1 -DDIRENT=1 -DHAVE_SYS_MTIO_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRSTR=1 -DHAVE_MKDIR=1 -DHAVE_MKNOD=1 -DHAVE_RENAME=1 -DHAVE_FTRUNCATE=1 -DHAVE_VPRINTF=1 -DHAVE_ALLOCA_H=1 -DDEF_AR_FILE=\"/dev/tape\" -DDEFBLOCKING=20 -I. -I. tar.c
accom: Error: /usr/include/stdlib.h, line 102: Qualifier mismatch in prototype,   pointer toconst  char  versus   pointer to char
       extern int       system(  char *);
       ---------------------------------^

I discovered that this is because stdio.h defines system() to take a
'const char *' as an argument, and later port.h #define's const out of
existence.  After this occurs stdlib.h defines system() again, but
this time the 'const' key word is deleted.  These problems would have
been avoided if __STDC__ where defined so I reran configure with 
CC="cc -ansi", the stringent ANSI version of the IRIX C compiler.
Nevertheless this problem might be avoidable right from the start.

Following this I ran into an error related to passing restore_times
as the second argument to utime().  It seems that on the SGI utime()
takes a second argument of type 'struct utimbuf *', which of course
only contains two time_t elements.  restore_times is just an array
of two time_t values, but the type checking fails generating a fatal
compiler error.  I am not if struct utimbuf exists on all machines, 
but it does exist on most of the machines I checked.   I leave the
final solution of this problem to you.


Tiring somewhat of these prototyping problems, I reconfigured using 
CC="cc -cckr" (K & R version).  The build was then uneventful with
the exception of #ifdef's spaced away from the beginning of the line 
in expand.c, and buffer.c.

ie.
    #ifdef __MSDOS__

In my experience a wide range of systems can grok the following:

#    ifdef __MSDOS__

so you might consider using that style of preprocessor identation
if you really want to indent preprocessor directives.

One thing that was rather perturbing was when the 'make install'
procedure replace my system /etc/rmt without much warning.  While
I realize in retrospect that this was mentioned in the README, it
still caught me by surprise.  Perhaps this ought to be rethought
a little.

I am still looking into how well GNU tar actually runs.  I will 
update you on this.  Keep up the good work!

-------------------------------------------------------------------------------
Frank Warmerdam | Who can give them back their lives | warmerda@pci.on.ca    
Software Artist | and all those wasted years? - Rush |

Newsgroups: gnu.utils.bug
From: egan@upl.COM (Egan F. Ford)
Subject: tar 1.11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Sep 1992 18:25:45 GMT

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:

parse error before `const'
gnu.c:289: syntax error before `void'
gnu.c:290: syntax error before `void'
gnu.c:291: parse error before `{'
gnu.c:294: warning: initialization of `frst' makes integer from pointer
withoutt
gnu.c:294: initializer element for `frst' is not constant
gnu.c:295: warning: initialization of `scnd' makes integer from pointer
withoutt
gnu.c:295: initializer element for `scnd' is not constant
gnu.c:297: parse error before `return'
gnu.c: In function `get_dir_contents':
gnu.c:427: `dirent_cmp' undeclared (first use this function)
gnu.c:427: (Each undeclared identifier is reported only once
gnu.c:427: for each function it appears in.)
gmake: *** [gnu.o] Error 1

So I tryed "gmake CC=cc".  errors:

bison -y  getdate.y             (also tryed yacc and yacc -Sw600)
conflicts:  9 shift/reduce
mv -f y.tab.c getdate.c
cc -c -g  -DMAJOR_IN_SYSMACROS=1 -DDIRENT=1 -DNO_REMOTE=1 -DSTDC_HEADERS=1...
getdate.c
cc -g -o tar tar.o create.o extract.o buffer.o getoldopt.o update.o gnu.o...
mangl 
ld: Symbol valloc in malloc.o is multiply defined. First defined in port.o
gmake: *** [tar] Error 1
rm  getdate.c

Sooo... I tryed removing valloc in port (I tryed malloc later) and then
gmake CC=cc.  errors:

undefined                       first referenced
 symbol                             in file
alloca                              getopt.o
ld fatal: Symbol referencing errors. No output written to tar
gmake: *** [tar] Error 1

So I add alloca.c to SRC and alloca.o OBJ in the Makefile and
gmake CC=cc.  no errors.

tar appears to create .tar and .tar.Z archives very well, and to tar Ztvf.
However when creating a tar archive using cvf you get L\001\004 as the output 
for each file name.  When using tar xvf or xf, many of the files pipe to 
stdout and fails to restore the files.

I hope this helps.  If you have any help I'd appreciate it.

Thanks.

-- 
Egan F. Ford
uunet!cbs!egan      
upl.com!neb!cbs!egan


Newsgroups: gnu.utils.bug
From: aki@akix.UUCP (Aki Atoji)
Subject: binutils-2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 6 Sep 1992 17:52:00 GMT

Older SYSV R3 machines do not have rename() call, causing linking of
binutils/ar to abort with an unresolved error.

The following is a patch to libiberty/functions.def and a trivial new file
libiberty/rename.c to solve the above problem.

Host system:  ISC 2.0.2 (any stock SVR3)
Binutils-2.0 configured with:  configure i386v
Binutils-2.0 built with:       make CC="gcc" CFLAGS="-O2 -g"

==============================================================================

*** functions.def~	Sun Sep  6 10:18:44 1992
--- functions.def	Sun Sep  6 10:13:35 1992
***************
*** 24,29 ****
--- 24,30 ----
  DEF(memmove, PTR, (s1, s2, length), PTR s1 AND CONST PTR s2 AND size_t length)
  DEF(memset, PTR, (s, val, length), PTR s AND int val AND size_t length )
  DEF(random, long int, (), NOTHING)
+ DEF(rename, int, (from, to), CONST char *from AND CONST char *to)
  DEF(rindex, char*, (s, c), char *s AND int c)
  DEF(strchr, char*, (s, c), CONST char *s AND int c)
  DEF(strdup, char*, (s1), char * s1)

=================================rename.c=====================================
/* 
 * emulate rename() on AKOS realtime kernel.
 * rename.c  Copyright (C) 1992,  Aki Atoji   aki@akix.uucp

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  
*/

int rename (const char *from, const char *to)
{
  int result;
  return (result = link(from, to)) ? result : unlink(from);
}

===========================================================================

---------------------------------------------------------------------------
Aki Atoji   Graphics, Networking, Embedded Realtime and Japanese Consulting
           aki@akix.uucp                      crash!akix!aki@trout.nosc.mil

"What Vegemite is to Australians, what Natto is to Japanese.  Now, don't
 even ask about this Peanut Butter and Jelley stuff."   -- Aki
---------------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: carlton@husc.harvard.edu (david carlton)
Subject: Re: more thoughts on fileutils
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 5 Sep 1992 18:55:12 GMT

Are hurd's system calls going to use the presence or absence of a
trailing "/" to tell whether a directory/file node is being used as a
directory or a file?  If not, how will that work?

david carlton
carlton@husc.harvard.edu

       The SAME WAVE keeps coming in and COLLAPSING like a rayon
       MUU-MUU..

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: tar 1.11: missing files
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 15:06:54 GMT

The Makefile in tar 1.11 still wants tar.texinfo to exist, even though
it's been (temporarily, I realize) removed from the distribution.

Also, malloc.c needs getpagesize.h (on a Sun 4 running SunOS 4.1,
compiling with gcc 2.2.2).  I copied it from Emacs.

karl@cs.umb.edu

Newsgroups: gnu.utils.bug
From: hooft@xray.chem.ruu.nl (R.W.W. Hooft)
Subject: SED-1.09 fails on PAIRUP script from ISPELL v3.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Sep 1992 09:47:53 GMT

Hello,

On my linux machine I have had problems with ispell, which I could
track down to a suspected bug in gnu SED-1.09. I am certainly not
an sed-expert, but since this problem can be demonstrated from a 
200 byte script and an 8 byte datafile, I think it must be possible
for you to locate it.

The script has been tested to:
  1) fail with gnu-sed on linux V0.97pl4
  2) fail with gnu-sed on ES/OS V2.0
  3) fail with gnu-sed on Ultrix V4.2A
  4) work correctly with ES/OS-sed on ES/OS 2.0
  5) work correctly with Ultrix-sed on Ultrix V4.2A

I append a uuencoded compressed tar file, containing a file of test
data and the script. I hope I supplied enough information for you
to track down this problem.

begin 644 sedbug.tar.Z
M'YV09,+0"0.@H,&#"!,J7,BPH<.'$!&"F&B#!@T0 ":"B&$1HT:.%S-J'+D1
MQL0:,FK0N&&Q!@P9&F^PK)$11L2;.'/JW F@SIR!<B8"D/-&#$^&/LO(F7.T
MJ=.G4*-*G1HQ" @A((: (** JM>O8,.*'4NVK-FS:-.J50@G3!HY=>"XF(-F
MK=V#,6O4\#@1)-^-'462!#%CAHV3*5=:I&'C1M\8,&+0!&'SKN6%/H$*)6IT
M:M*EET.+'HUS1(@78M*X>4%7P0@05-"DF0-BSA@Y:>#0J8WF31TV9$#<+B.P
M#(@P(,RD86/\C1D0;=_2/F%5R D0U+.>8('=*I'K9HBV.>[&-0C5<.K04<Z\
M^]6L6[>#$*/^_&XR;\K,<7."C@L05Z"1QP^N*0!%$$E(4044/9SP @@O[*' 
M2'/LX 47*&SA!0A=J,!%"B!@J"&''J: H0LE[L!%#"'*P(4"*W(QPPX3:@1%
MC1-Q-5(?)R@P1QG!M> &""*0<&"""XK0%6E,-NGDDU!&*>645%9IY9589JGE
MEEQVZ>678(8IYIADEFGFF6BFJ>::;+;IYIMPQBGGG'36:>>=>.:IYYY\]NGG
MGX &*NB@A!9JZ*&()JKHHHPVZNBCD$8JZ:245FKII9AFJNFFG';JZ:>@ABKJ
#J%$!
 
end

-- 
Rob W.W. Hooft,  Department of crystal and structural chemistry
Bijvoet Center for Biomolecular Research, University of Utrecht
The Netherlands ===== hooft@chem.ruu.nl (hooft@hutruu54.bitnet)

Newsgroups: gnu.utils.bug
From: halvers@sol.CRd.ge.COM (peter c halverson)
Subject: imageto dumps core with untyped input filename
Reply-To: Pete Halverson <halverson@crd.ge.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 21:49:31 GMT

Problem Description:

Assuming an IMG input file with the name "gbbb.img", imageto dumps core
with a segmentation fault given the arguments:

    % imageto gbbb

(e.g. accidently omitting the ".img" extension).

Cursory investigation reveals that in the routine "set_input_format" in
"imageto/main.c" is not checking for a NULL return value from "find_suffix"
before doing STREQ comparisons on the result.  

Suggested fix:

   imageto/main.c:
   998c998
   <   if (STREQ (input_extension, "img"))
   ---
   >   if (input_extension && STREQ (input_extension, "img"))
   1001c1001
   <   else if (STREQ (input_extension, "pbm"))
   ---
   >   else if (input_extension && STREQ (input_extension, "pbm"))
From: ezk@ground.cs.columbia.edu (Erez "HWank1" Zadok)
Subject: A problem with double-quotes when installing gnu finger 1.35
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 7 Sep 1992 04:00:51 GMT

THE SITUATION:

Running ./configure and make creates these .fingerdir, .bindir, .etcdir and
.targetdir files.  They contain paths which are double quoted.  When doing
"make server" or "make client", these dot files get cat-ed within backquotes
to get their contents.


THE PROBLEM:

My default shell, ksh (version 88d) regards the single back-quotes as quotes
on top of the contents of the dot files, which by themselves contain
double-quotes.  When the "make server" or "make client" tries to do

	mkdir `cat ...`

it attempts to create a directory whose name *contains* the double-quotes.
When I got to that install stage, I had to manually edit out those
double-quotes from the dot files.  Only then did the install complete.

I have not tried to change my default shell to /bin/sh, csh, or bash.  What
did you folks use?


MY SETUP:

- GNU finger 1.35
- Sun-4's: everything from 4/25 to 4/630.
- Compiler used: gcc 2.2.2
- OS version SunOS 4.1.2
- network configuration: class B, subnets, ciscos, "the usual" stuff.  Not
  really relevant to this bug.  We nfs-automount many directories.
- Patches: none.

Erez Zadok.
Mobile Computing Laboratory.
Columbia University Department of Computer Science.
---
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

Newsgroups: gnu.utils.bug
From: brown@quorum.COM (Robert E. Brown)
Subject: GNU tar version 1.11 bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 20:21:37 GMT

Running GNU tar version 1.11 on a Next with OS release 2.1 ...

GNU tar seems unable to read its own archives when file names get long.

COMMAND:  ~/etc/garbage/tar-1.11/tar cf - apps/illustrator3.0.1 |  ~/etc/

OUTPUT:

garbage/tar-1.11/tar tf -
apps/illustrator3.0.1/
apps/illustrator3.0.1/Gallery%20Disk/
apps/illustrator3.0.1/Gallery%20Disk/Gallery%20Installer
apps/illustrator3.0.1/Gallery%20Disk/_Gallery%20Installer
apps/illustrator3.0.1/Gallery%20Disk/PPD%20Installer
apps/illustrator3.0.1/Gallery%20Disk/_PPD%20Installer
apps/illustrator3.0.1/_Gallery%20Disk
apps/illustrator3.0.1/Program%20Disk/
apps/illustrator3.0.1/Program%20Disk/Adobe%20Illustrator%A8%203%20Installer
apps/illustrator3.0.1/Program%20Disk/_Adobe%20Illustrator%A8%203%20Installer
apps/illustrator3.0.1/Program%20Disk/Read%20Me%203.0.1%20%28TeachText%29
apps/illustrator3.0.1/Program%20Disk/_Read%20Me%203.0.1%20%28TeachText%29
apps/illustrator3.0.1/Program%20Disk/TeachText
apps/illustrator3.0.1/Program%20Disk/_TeachText
apps/illustrator3.0.1/_Program%20Disk
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/Adobe%20Separator%203.0.2
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_Adobe%20Separator%203.0.2
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/Densitometer%20Control%20Chart
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_Densitometer%20Control%20Chart
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/DrawOver%203.0
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/_DrawOver%203.0
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/PANTONE%A8%20NEC
/toe/brown/etc/garbage/tar-1.11/tar: Skipping to next file header...
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/_PANTONE%A8%20NEC
/toe/brown/etc/garbage/tar-1.11/tar: Skipping to next file header...
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/PANTONE%A8%20Oc%8E%20G5232
/toe/brown/etc/garbage/tar-1.11/tar: Skipping to next file header...
apps/illustrator3.0.1/Tutorial%20%26%20Utilities/PANTONE%A8%20Color%20Look%2Dup%20tables%A9%20/_PANTONE%A8%20Oc%8E%20G5232

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: trailing slashes
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 9 Sep 1992 12:54:52 GMT

(going back to the trailing slash discussion here)

    Most importantly, don't assume what people "want" in this environment,
    [the hurd, that is]

I don't want to assume any such thing!

    Most important is to make everything *possible* and then *convenient*.

I completely agree.

    the functionality I'm building
    in to the operating system be made available to users using ordinary
    shell utilities.

Fine.  But I don't want the existing convenience of mv to go away!  It
is very convenient for me, and I think others (although doubtless not
everyone), that
  (1) completion routines append / when they see a directory
  (2) that the utilities therefore ignore trailing slashes on directories

I'm probably just being dense, but I still don't see why this is such a
bad thing.

Your new file&directory nodes are not directories.  So the above doesn't
apply, it seems to me.  It would inappropriate for the completion
routines to append a / in the first place.

For that matter, what should ls -F report for these nodes (what does
stat return on them?)?  Perhaps a new trailing symbol should be invented
-- `:', maybe?  Then completion routines can append that new symbol,
the file utilities can be made to understand it, and everyone will be
happy.

Alternatively, I suppose a new symbol isn't really necessary.  The
completion routines could just not append anything, and the user can put
in a slash if desired.

But this is just speculation -- working out how these new nodes work
most conveniently is something we probably cannot do without actually
having them around to play with.
From: mib@gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: gnu.utils.bug
Subject: more thoughts on fileutils
Date: 8 Sep 92 10:06:08 GMT
Distribution: gnu
Organization: GNUs Not Usenet


   Idol: Herbert Gro"nemeyer
   Date: Sat, 05 Sep 92 22:55:12 -0400
   From: david carlton <carlton@husc.harvard.edu>
   X-Mts: smtp

   Are hurd's system calls going to use the presence or absence of a
   trailing "/" to tell whether a directory/file node is being used as a
   directory or a file?  If not, how will that work?

The file calls are a completely different set from the directory
calls, so theree is no need to disambiguate.  Attempts to look up
things which aren't directories, when a trailing slash is given, will
fail with ENOTDIR.

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

Regarding my previous posting, it seems so far that *all* extractions
show this problem of:

tar: couldn't change access and modification times of [lines of garbage]
tar: cannot change mode of file [lines of garbage]

with each [lines of garbage] sometimes being many pages long.  This
renders GNU tar unusable for practical purpose on this system.  The
problems I reported with "tar c..." this morning and these problems
with "tar x" are fairly solid, this shakes a little the confidence I
would like to have for my main archiver.  So, I am reverting to tar
1.10 for now, waiting for correcting patches.

Looking at the ChangeLog, I did not find specific trace of correction
for the problem of -dM combination not working on floppies.  I
reported this problem at each release since GNU tar 1.08.  Does
someone know if the problem has been corrected in GNU tar 1.11?

-- 
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: slester@vetmed.wsu.edu (Samuel M. Lester)
Subject: Gnu-Tar Find, Thanks
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 10 Sep 1992 00:05:40 GMT

	
                                                  
                           Sam Lester              
                     
	
Mailer: Elm [revision: 70.30]

Dear GNU people,


   Thanks ever so much for the nice find and tar utilities.  I was wondering
   if anyone ever got tar to work on an HP9000/800 or 700.  I compile it, and
   it pucks when I run it.  

   On the other hand,  I just got find3.7 and it works fine,  have you guys
   ever thought about adding up all the filesizes in the find C-program and
   printing it at the end ?? Just a thought, saves awking stuff.


   thanks ever so much


   Sam Lester


--

   _____________________________________________________________________   
  |                                                                     |  
  |                                                                     |
  | slester@pgavin1.vetmed.wsu.edu  slester@eecs.wsu.edu   INTERNET     |
  |                                                                     |
  |                 slester@wsuvm1.csc.wsu.edu     BITNET               |
  |                     Sam@509.335.0812          AT&T NET              |
  |                     Sam@509.335.0811          AT&T FAX Ola NET      |
  |                                                                     |
  |    USPS  Sam Lester                                                 |
  |    USPS  College of Veterinary Medicine Washington State University |
  |    USPS  Bustad Hall        Mail Stop 7010                          |
  |    USPS  Pullman, WA 99163-7010                                     |
  |                                                                     |
  |_____________________________________________________________________|
From: eggert@bi.TWinsun.COM (Paul Eggert)
Newsgroups: gnu.utils.bug
Subject: typo in regex 0.10 prevents use in pre-ANSI C
Date: 11 Sep 92 15:38:20 GMT
Distribution: gnu
Organization: GNUs Not Usenet

A typo in regex.h causes compilation to fail in pre-ANSI C compilers
(e.g. SunOS 4.1.2 cc).  Here is a patch.

===================================================================
RCS file: RCS/regex.h,v
retrieving revision 0.10
diff -c -r0.10 regex.h
*** regex.h	1992/09/09 10:33:48	0.10
--- regex.h	1992/09/11 15:25:23
***************
*** 396,402 ****
  #if __STDC__
  #define _RE_ARGS(args) args
  #else
! #define _RE_ARGS(args)
  #define const
  #endif
  
--- 396,402 ----
  #if __STDC__
  #define _RE_ARGS(args) args
  #else
! #define _RE_ARGS(args) ()
  #define const
  #endif
  
Newsgroups: gnu.utils.bug