HDTenEightyP/NetNews huggingface dataset:
From: johns@haggis.ccsf.caltech.edu (John Salmon)
Subject: gdb string-printing feature request
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 03:59:35 GMT

I have a program which, because of notoriously unreliable I/O facilities
on the machines I typically use, writes a large amount of status
information into an internal character array.  This information is
the kind of thing you might normally send to stderr if you have DEBUG
turned on.  When the program is under gdb control, I would like to be
able to print this string to the terminal with newline characters in the
string appearing as line breaks in the output.  Gdb insists on printing
newlines as "\n", and formating everything onto a single output line (which
wraps several hundred times on my terminal window).

Any assistance would be appreciated, i.e., new features in gdb, or simply
pointing out that this can be done already, and I haven't read the manual
carefully enough.

Here's a short example:
-------------what I get now---------------------
(gdb) print dbgbuf
$1 = {"###proc 0\nrmin=(-1, -1, -1)\nrmax=(0.966874, 0.911626, 0.988096)\nBuildTree  nobj = 30\nstart pqsort, *base at dcdf8\npqsort max-min combines\npqsort done, *base at dcdf8\nAfter Decomp, nobj = 30\nMade local"...}
(gdb) 

---------------what I would like-----------------------
(gdb) print dbgbuf
$1 = {"###proc 0\nrmin=(-1, -1, -1)
rmax=(0.966874, 0.911626, 0.988096)
BuildTree  nobj = 30
start pqsort, *base at dcdf8
pqsort max-min combines
pqsort done, *base at dcdf8
After Decomp, nobj = 30
Made local"...}
(gdb) 
-------------------------------------------------------

Thanks,
John Salmon		 Internet: johns@delilah.ccsf.caltech.edu
206-49 Caltech		 UUCP: johns%delilah.ccsf.caltech.edu@uunet.uu.net
Pasadena, CA 91125 USA	 Bitnet: johns@caltech.bitnet
(818)356-2907		 delilah.ccsf.caltech.edu=[131.215.145.137]



Newsgroups: gnu.gdb.bug
From: drmorris@us.oracle.COM (Dave Morrison)
Subject: gdb 4.6 bug with longjmp breakpoints and sun sys5 libs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 03:35:51 GMT

It came to my attention that the simple longjmp program:

#include <setjmp.h>

main()
{
   jmp_buf env;
   int err;
   
   if (err = setjmp(env))
   {
      printf("World (%d)!\n", err);
   } else {
      printf("Hello, ");
      longjmp(env, 1);
   }
}

was not working when stepped/nexted, but worked fine when run normally
or continued through.  Looking at some breakpoints, I saw:

(gdb) mai in br
Num Type           Disp Enb Address    What
-1  longjmp        keep n   0x00002404  <longjmp>
-2  longjmp        keep n   0x00002404  <longjmp>
-3  longjmp resume keep n   0x00000000  <_DYNAMIC>
1   breakpoint     keep y   0x0000227c in main at jmptest.c:5
(gdb)

Multiple breakpoints on the same address, hmmm.  Well, turns out this
was compiled using the sys5 libraries (on sunos 4.1.2) which has:

% nm /usr/5lib/libc.a | grep jmp
_setjmp.o:
0000002c T __longjmp
00000000 T __setjmp
0000002c T _longjmp
00000000 T _setjmp

Yes, folks, longjmp and _longjmp are the *same*.  Gdb sets breakpoints
for longjmp, _longjmp, and siglongjmp, and never checks for duplicates
believing that they will be always be different.  Ooops?

This small little patch seems to get me by for the time being.  I didn't
put a lot of thought into the correctness of the patch.  Someone with
more know how than I should take a look at the longjmp breakpoint code,
and see how it should make sense with the above in mind.

----------------------------------------------------------------------
*** breakpoint.c	Wed Aug 12 04:30:29 1992
--- breakpoint.c-dist	Mon Jul  6 10:10:37 1992
***************
*** 1290,1299 ****
  
    ALL_BREAKPOINTS (b)
      if (b->type == bp_longjmp)
!     {
!        b->enable = enabled;
!        check_duplicates (b->address);
!     }
  }
  
  void
--- 1290,1296 ----
  
    ALL_BREAKPOINTS (b)
      if (b->type == bp_longjmp)
!       b->enable = enabled;
  }
  
  void

Newsgroups: gnu.gdb.bug
From: pfieland@cyclonic.sw.stratus.com (Peggy Fieland)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 19:32:10 GMT

Gdb-4.6 fails to properly demangle member functions whose names end
in an underscore.  The problem occurred on both a Sun Sparc and
Stratus FTX (i860).

Here is the test program

  class complex
      {
      double r;
      double i;
      public:
              complex(){};
              complex(double x,double y); 
          long funny_name_ (long l);

      };

long complex::funny_name_ (long l)
{
 return l;
}

 complex::complex(double x, double y)
{
r=x; 
i=y;

}
long plus (long l, long m)
{
 return (l + m);
}

main()
{

complex cc;

}

Here is the gdb session: 
cyclonic-tests% gdb46 cx
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) set demangle-style cfront
(gdb) info functions
All defined functions:

File complex.c:
struct complex *complex::complex(double, complex);
int funny_name___7complexFl();
int main();
int plus(long, long);

Here is the fix:


*** /home/tools/gnu/gdb-4.6/gdb/cplus-dem.c	Tue Jul 14 03:34:20 1992
--- cplus-dem.c	Mon Aug 10 09:58:32 1992
*** 894,901 ****
--- 903,920 ----
  {
    int success = 1;
    const char *scan;
+   int i;
+   
  
    scan = strstr (*mangled, "__");
+ /* Peggy Fieland. Some function names end in _s. */
+   if (scan != NULL)
+      {
+         i = strspn (scan, "_");  /* get number of _s */
+         if (i > 2)
+            scan += (i - 2); 
+      }
+  
    if (scan == NULL)
      {
        if (current_demangling_style == auto_demangling ||
***************
*** 908,913 ****
--- 927,933 ----
  	  success = 0;
  	}
      }
+ 
    else if (work -> static_type)
      {
        if (!isdigit (scan[0]) && (scan[0] != 't'))
***************

Newsgroups: gnu.gdb.bug
From: rjc@devo.unify.COM (Ronald Cole)
Subject: Re: HP700 running HPUX
Organization: Unify Corporation, Sacramento, California
Distribution: gnu
Date: Sun, 16 Aug 1992 16:00:12 GMT

In article <DOUGG.92Aug13120200@kbsw3.kbsw1.uucp> dougg%kbsw3@kbsw1.UUCP (Doug Gerecht 806 1031) writes:
   In article <9208130252.aa15810@s.s.ms.uky.edu> randy@ms.UKy.EDU (Randy Appleton) writes:

      I'm trying to get gdb4.6 dated July 14th running on our HP 700 series
      workstations under hpux.  Is this a suported configuration?

      I have run "configure hppahpux" in the gdb-4.6 directory.  This for
      some reason did not configure the subdirectories, such as readline,
      mmalloc, etc.  So I manually ran the same configure on the subdirectories.

   Get the HP support via ftp from jaguar.cs.utah.edu, in
   dist/pa-gdb-4.6.tar.Z.

It should be noted that pa-gdb only supports pa-gcc.  That is to say that
you cannot use pa-gdb to debug programs compiled with the native compiler.
I found out the hard way, since this "fact" is not documented.

--
Ronald Cole           +----------------------+  internet: rjc@unify.com
Software Engineer II  | This space for rent. |  uucp:     uunet!unify!rjc
Unify Corporation     +----------------------+  voice:    +1 916 928 6238
          "THE BILL OF RIGHTS --- Void where prohibited by law"

Newsgroups: gnu.gdb.bug
From: ath@lcs.mit.edu (Andrew Heybey)
Subject: mips floating-point register printing
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 08:52:25 GMT

gdb-4.6, "configure decstation"

Couple of minor bugs in printing out the registers for the mips
architecture.  raw_buffer is not large enough so the stack was being
stomped in mips_print_register(), and REGISTER_VIRTUAL_TYPE() did not
return the correct type for the floating-point registers.

It's not clear whether the odd-numbered floating-point registers
should be printed as floating-point numbers or not since they cannot
be used for floating-point operations--they are only used for loading
and storing.  Beats me, so I left it alone.

andrew

*** /tmp/RCSAa08527	Wed Aug 19 12:38:22 1992
--- mips-tdep.c	Wed Aug 19 11:51:07 1992
***************
*** 533,539 ****
  mips_print_register(regnum, all)
       int regnum, all;
  {
!       unsigned char raw_buffer[MAX_REGISTER_RAW_SIZE];
        REGISTER_TYPE val;
  
        /* Get the data in raw format.  */
--- 533,539 ----
  mips_print_register(regnum, all)
       int regnum, all;
  {
!       unsigned char raw_buffer[MAX_REGISTER_RAW_SIZE*2];
        REGISTER_TYPE val;
  
        /* Get the data in raw format.  */
*** /tmp/RCSAa08536	Wed Aug 19 12:38:40 1992
--- tm-mips.h	Wed Aug 19 11:51:51 1992
***************
*** 190,196 ****
  /* Return the GDB type object for the "standard" data type
     of data in register N.  */
  
! #define REGISTER_VIRTUAL_TYPE(N) builtin_type_int
  /* Store the address of the place in which to copy the structure the
     subroutine will return.  This is called from call_function. */
  
--- 190,199 ----
  /* Return the GDB type object for the "standard" data type
     of data in register N.  */
  
! #define REGISTER_VIRTUAL_TYPE(N)  \
! 	(((N) >= FP0_REGNUM && (N) < FP0_REGNUM+32)  \
! 	 ? builtin_type_float : builtin_type_int) \
! 
  /* Store the address of the place in which to copy the structure the
     subroutine will return.  This is called from call_function. */
  

Newsgroups: gnu.gdb.bug
From: dougg%kbsw3@kbsw1.UUCP (Doug Gerecht 806 1031)
Subject: Re: HP700 running HPUX
Organization: Kentek Information Systems
Distribution: gnu
Date: Thu, 13 Aug 1992 16:02:00 GMT

In article <9208130252.aa15810@s.s.ms.uky.edu> randy@ms.UKy.EDU (Randy Appleton) writes:

   I'm trying to get gdb4.6 dated July 14th running on our HP 700 series
   workstations under hpux.  Is this a suported configuration?

   I have run "configure hppahpux" in the gdb-4.6 directory.  This for
   some reason did not configure the subdirectories, such as readline,
   mmalloc, etc.  So I manually ran the same configure on the subdirectories.

Get the HP support via ftp from jaguar.cs.utah.edu, in
dist/pa-gdb-4.6.tar.Z.


-- 

		dougg@kentek.com	Doug Gerecht


Newsgroups: gnu.gdb.bug
From: Anund.Lie@idt.unit.no (Anund Lie)
Subject: Gdb has problems with breakpoints after program file update
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 17:34:47 GMT

(The problem concerns at least gdb 4.5 and 4.6 on SPARC.)

When gdb detects that the executable file it is debugging has changed,
it re-reads the symbol table and attempts to restart with the same
breakpoints and watchpoints on the new version of the file, but is
then unable to examine and set the breakpoints.

Anund Lie
Division of Computer Systems and Telematics 
Norwegian Inst. of Technology, N-7034 Trondheim, Norway
Email: Anund.Lie@idt.unit.no       (Internet)

--------------------------------------------------------------------
villtind% cat t.c
int
main(argc,argv)
int argc;
char *argv[];
{
    return argc;
}
villtind% gcc -g -o t t.c
villtind% gdb t
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) b main
Breakpoint 1 at 0x22a4: file t.c, line 6.
(gdb) run
Starting program: /a/grimne/src/PRINTER/psdriver/sun4/t 

Breakpoint 1, main (argc=1, argv=0xf7fff874) at t.c:6
6           return argc;
(gdb) cont
Continuing.

Program exited with code 01.
(gdb) 
Suspended
villtind% !gcc
gcc -g -o t t.c
villtind% %gdb
gdb t
(gdb) run
`/a/grimne/src/PRINTER/psdriver/sun4/t' has changed; re-reading symbols.
Error in re-setting breakpoint 1:
Cannot access memory at address 0x2290.
Error in re-setting breakpoint 1:
Cannot access memory at address 0x2290.
Starting program: /a/grimne/src/PRINTER/psdriver/sun4/t 
Breakpoint 1 at 0x22a4: file t.c, line 6.

Program exited with code 01.
(gdb) quit 
villtind% 

Newsgroups: gnu.gdb.bug
From: ath@lcs.mit.edu (Andrew Heybey)
Subject: mmalloc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 08:37:16 GMT

gdb-4.6, "configure decstation"

sbrk() does not always return a word-aligned pointer.  As a specific
example, when linked with profiling under ultrix 4.2 the sbrk() in
__mmalloc_sbrk_init() returns an odd pointer.

andrew

*** /tmp/RCSAa08406	Wed Aug 19 12:15:05 1992
--- sbrk-sup.c	Wed Aug 19 12:07:29 1992
***************
*** 59,66 ****
--- 59,78 ----
  __mmalloc_sbrk_init ()
  {
    PTR base;
+   int align;
  
+   /* What sbrk() returns is not guaranteed to be word-aligned (at least 
+    * ultrix has demonstrated such behavior).  Round base up to
+    * be double word aligned just to be safe.
+    */
+ #define ALIGNMENT 8
    base = sbrk (0);
+   align = (int)base & (ALIGNMENT - 1);
+   if (align)
+     {
+       sbrk (ALIGNMENT - align);
+       base = sbrk (0);
+     }
    __mmalloc_default_mdp = (struct mdesc *) sbrk (sizeof (struct mdesc));
    memset ((char *) __mmalloc_default_mdp, 0, sizeof (struct mdesc));
    __mmalloc_default_mdp -> morecore = sbrk_morecore;

Newsgroups: gnu.gdb.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: info reg should take multiple args
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 13:17:35 GMT

Lameness:

(gdb) i r d0 d1
d0 d1: invalid register name.
(gdb) 


This should do the same as "i r d0" and then "i r d1".

Newsgroups: gnu.gdb.bug
From: liman@cpp.do.open.DE (Arnd Liman)
Subject: Bug in gnu tar?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 18 Aug 1992 15:55:22 GMT

Hello,

I am trying to use gtar 1.10 for our NeXT Stations. But after dumping serveral
files to tape, gtar quits with a segmentation violation.

With gdb I found, that the program crashes in tar.c in function
'name_from_list()':

/* This returns a name from the namelist which doesn't have ->found set.
   It sets ->found before returning, so successive calls will find and return
   all the non-found names in the namelist */

struct name *gnu_list_name;

char *
  name_from_list()
{
  if(!gnu_list_name)
    gnu_list_name = namelist;
  while(gnu_list_name && gnu_list_name->found)  <<<--------------
    gnu_list_name=gnu_list_name->next;
  if(gnu_list_name) {
    gnu_list_name->found++;
    if(gnu_list_name->change_dir)
      if(chdir(gnu_list_name->change_dir)<0)
        msg_perror("can't chdir to %s",gnu_list_name->change_dir);
    return gnu_list_name->name;
  }
  return (char *)0;
}

I marked the line, where the segmentation violation occured. The reason
was the corrupted list 'namelist'. After some elements (~100) the 'next'
pointer in 'struct name' points to an area where many filenames are
stored. I didn't find the reason for this, maybe you have an idea?

Here are the options that I give to gtar:

tar -c +multi-volume +one-file-system +block=124 -f /dev/rst0
    +listed-incremental /etc/tar-backup/temp.level-0
    +label='Full backup of / on majestix at 18.08.92' -C / .

The /-filesystem is 350 MB big.

Can you help me???

Arnd

-- 
   __          _
  /  )       _//                       Mail Addr. liman@cpp.do.open.de
 /--/        /                                    Baroper Strasse 261
/  (_ rnd   /___ iman                             D-4600 Dortmund 50

Newsgroups: gnu.utils.bug
From: tmb@idiap.CH (Thomas M. Breuel)
Subject: Re: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 22 Aug 1992 21:31:14 GMT

|> The fix is not indiscriminate bashing of trailing slashes, as
|> currently implemented.  The fix is to remove the generic truncation of
|> trailing slashes, then to fix whatever minor bugs prevent the use of
|> pathnames containing trailing slashes.
|
|Fix everyone's shells, or everyone's kernels?

I don't think there is anything to fix in either the shell or the
kernel. File completion in bash is just fine (I like getting trailing
slashes for directories), as is the behavior of the UNIX kernel of not
accepting trailing slashes in certain situations.

|I don't offhand see a
|better solution than what the GNU utilities currently do.  But
|specific suggestions are welcome.

I have come to rely on the fact that if I write "mv foo bar/" and "bar"
is a plain file, I get an error message, rather than have "mv" silently
remove "bar". What would you say if type checking were suddenly removed
from ANSI C?  

If you want this non-standard behavior in the GNU file utilities, maybe
you can make it optional via an environment variable.  I certainly
don't feel safe using the current GNU file utilities, and, furthermore,
I wonder what other dangerous "improvements" may have been made.

				Thomas.

Newsgroups: gnu.utils.bug
From: gnu@cygnus.com
Subject: diff: allow a few control chars in an ascii file
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 15:40:58 GMT

GNU diff wouldn't compare formatted "info" files, so I made this change.
It will now ignore the ^_'s between nodes, if they are <1.5% of the file.

A split info database's main file will have a large preponderance of
\177's (one per line, roughly, in the tag table) which still makes
diff think that it is a binary file.

Does anyone know why tag tables in `info' files use \177 to delimit
the node name from its offset?  Certainly ',' could be used, since it
is the delimiter of node names in an @node command.  Or the offset
could simply by the last number on the line (everything else is the
node name).  This would require simple changes in makeinfo.c, info.c,
and the Emacs info reader, which I'd be willing to make.

	John Gilmore

diff -u -r1.1.1.4 io.c
--- 1.1.1.4	1991/02/12 07:24:57
+++ io.c	1992/08/12 03:41:23
@@ -31,7 +31,10 @@
 
 /* Check for binary files and compare them for exact identity.  */
 
-/* Return 1 if BUF contains a non text character.
+/* Return 1 if BUF is a binary file.
+   We use a heuristic that allows a few odd control characters through
+   (such as used in RMAIL or Info files) but rejects files that have
+   more than a small percentage of control chars.
    SIZE is the number of characters in BUF.  */
 
 static int
@@ -74,9 +77,13 @@
     1, 1, 1, 1, 1, 1, 1, 1,
     1, 1, 1, 1, 1, 1, 1, 1,
   };
+  int maxallowed = 1 + ((unsigned)size) / 64;	/* Allow 1.5% control chars */
+  int binchars = 0;
+
   while (--size >= 0)
     if (!textchar[*buf++ & 0377])
-      return 1;
+      if (++binchars > maxallowed)
+	return 1;
   return 0;
 }
 
===================================================================
diff -u -r1.12 ChangeLog
--- 1.12	1992/07/04 14:59:37
+++ ChangeLog	1992/08/12 05:19:11
@@ -1,3 +1,10 @@
+Tue Aug 11 22:18:06 1992  John Gilmore  (gnu at cygnus.com)
+
+	* io.c (binary_file_p):  Use heuristic to avoid declaring info
+	files as binary files.  Allow about 1.5% non-printing
+	characters (in info's case, ^_).  This still loses for tag
+	tables, which are obnoxiously full of ^?'s.
+
 Sat Jul  4 07:49:43 1992  david d `zoo' zuhn  (zoo at cirdan.cygnus.com)
 
 	* diff.h: protect INT_MAX, CHAR_BIT, TRUE, FALSE from redefinition
From: nelson@reed.edu (Nelson Minar)
Newsgroups: gnu.utils.bug
Subject: bug in the GNU install v3.3 on Sequent Dynix v3.1.4 (BSD)
Date: 21 Aug 92 08:54:00 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Thank you, thank you, thank you for the GNU utils. I use them all the
time instead of the standard utilities. We use DECstations running
Ultrix and Sequents - both really old versions of BSD. Having modern
utilities like the fileutils, textutils, and shellutils is a real
help.

I just installed the fileutils v3.3 on our Sequents running Dynix v3.1.4,
and ran into a small bug with the install program. Here's an example:

(itchy) = cd /tmp
(itchy) = cat > foo
asdfasdf
(itchy) = /local/bin/gnu/install foo bar
/local/bin/gnu/install: bar: Not owner

however, the file "bar" is created just fine.

This happens every time I run install as a normal user - it doesn't
matter if I own the directory I am installing into. Nor does it matter
if I explicitly try to set the owner to myself with the --owner flag.
Install returns the error code 1.

Root does not have this problem.

(this problem does not show up with install version 3.2 on a
DECstation running Ultrix 4.2)

Without looking at the code at all, I'd guess that there's some
problem intepreting user modes with some Sequent old structure or
function call. But I haven't looked at it.

(incidentally, this makes the entire install of the utilities rather
painful, because GNU install reports an error code and "make install"
uses GNU install. Oops)
Newsgroups: gnu.utils.bug
From: dalen.via@sni.DE
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 13 Aug 1992 02:05:33 GMT

"GNU Bison version 1.18"

Line 904 in reader.c ends with a semicolon. I think this is wrong.

 !	  if (c != '*' && c != '/');
  	    continue;

 !	  if (c != '*' && c != '/')
  	    continue;


-----------------------------------------------------------------------------
     _            ____    NERV ....:   jan.via
    | |          |  _ \   Papermail:   Jan van Dalen,
    | |          | | \ \   	       Siemens Nixdorf Informatiesystemen BV
 _  | |  _    _  | |  ) )	       Mijlweg 9, 4131 PJ  Vianen, Nederland.
( (_| |  \ \/ /  | |_/ /  Phone ...:   +31-3473-65304
 \____|   \ _/   |____/   Fax......:   +31-3473-76504

             Usenet ....: jan.via@sni-usa.com
             Eunet  ....: jan.via@sni.de
-----------------------------------------------------------------------------

Newsgroups: gnu.utils.bug
From: jon@halsp.hitachi.COM (Jonathan Ryshpan)
Subject: binutils-beta-1.94
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 22:12:12 GMT

This name, taken from the latest binutils source tree, is too long to be
allowed by System V.  Maybe you could use something like binutils-1.94b.

Please acknowledge -- I don't trust the mail system here!

Many Thanks:

Jonathan Ryshpan		<...!uunet!hitachi!jon>

M/S 420				(415) 244-7369 
Hitachi America Ltd.
2000 Sierra Pt. Pkwy.
Brisbane CA 94005-1819

	===============> I write for myself ONLY. <===============

Newsgroups: gnu.utils.bug
From: jjc@jclark.com (James Clark)
Subject: sed 1.09
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 15 Aug 1992 17:11:46 GMT

I built sed 1.09 on a Sparc 2 running SunOS 4.1.1. gcc 2.2.2 was
installed and I had run fixincludes.  The make failed with memmove
undefined.  Here's a fix (this also fixes a similar problem with
memchr and updates configure.in for autoconf 1.0):

*** configure.in.~1~	Fri May 15 07:55:15 1992
--- configure.in	Sat Aug 15 18:09:16 1992
***************
*** 1,6 ****
  dnl Process this file with autoconf to produce a configure script.
  AC_INIT(sed.c)
! AC_PROG_GCC
  AC_PROG_CPP
  AC_PROG_INSTALL
  AC_MINIX
--- 1,6 ----
  dnl Process this file with autoconf to produce a configure script.
  AC_INIT(sed.c)
! AC_PROG_CC
  AC_PROG_CPP
  AC_PROG_INSTALL
  AC_MINIX
***************
*** 10,13 ****
--- 10,14 ----
  AC_CHAR_UNSIGNED
  AC_VPRINTF
  AC_ALLOCA
+ AC_HAVE_FUNCS(memmove memchr)
  AC_OUTPUT(Makefile)
*** utils.c.~1~	Tue Nov  5 07:15:58 1991
--- utils.c	Sat Aug 15 18:09:02 1992
***************
*** 207,213 ****
  	return ret;
  }
  
! #if !defined(USG) && !defined(STDC_HEADERS)
  /*
   * memchr - search for a byte
   *
--- 207,213 ----
  	return ret;
  }
  
! #ifndef HAVE_MEMCHR
  /*
   * memchr - search for a byte
   *
***************
*** 233,241 ****
  
  	return 0;
  }
! #endif
  
! #if !defined(STDC_HEADERS)
  /*
   * memmove - copy bytes, being careful about overlap.
   */
--- 233,241 ----
  
  	return 0;
  }
! #endif /* not HAVE_MEMCHR */
  
! #ifndef HAVE_MEMMOVE
  /*
   * memmove - copy bytes, being careful about overlap.
   */
***************
*** 267,273 ****
  
  	return(dst);
  }
! #endif
  
  /* Implement a variable sized buffer of 'stuff'.  We don't know what it is,
     nor do we care, as long as it doesn't mind being aligned by malloc. */
--- 267,273 ----
  
  	return(dst);
  }
! #endif /* not HAVE_MEMMOVE */
  
  /* Implement a variable sized buffer of 'stuff'.  We don't know what it is,
     nor do we care, as long as it doesn't mind being aligned by malloc. */


James Clark
jjc@jclark.com

Newsgroups: gnu.utils.bug