HDTenEightyP/NetNews huggingface dataset:
From: cef@blistr.mwc.COM (Charles  Fiterman, Froggy)
Subject: Installing 2.2 on ESIX V4
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 16 Oct 1992 18:07:45 GMT


I want to port to ESIX V4 to do some code generation experiments. I run into
a series of problems and feel lost. What setup is  correct? The version I
have builds great .s output calls the as fine and core dumps. The .o files
can be used to produce good output.

Also what is really going on with bcopy() etc. When do we build it and when
do we use memcpy() cccp.c seems to want to use these but not build them. I
suspect I've got something #defined wrong.

By the way one of the code generation experiments I want to try is a new
keyword nodefault: for switch statements. It means if not compiled for
optomize and a default: occurs abort(). If compiled for optomize assume that
no default may occur and jump the rails if the programmer is wrong. I think
this will make C more usefull for simulators etc by reducing the overhead of
switch statements. In short it means "trust me" it must be one of the cases
don't check. If there are cases for 0, 4, 8, and 12 the expression may be
added to the start of a table with no compares or shifting, and a branch
taken. If the programmer said "trust me" and was wrong tough. This may also
reduce some extrainious warnings about uninitialized variables.

I hope to have something usefull to add to gcc soon.


P.S. I have a 4 color incremental garbage collector based on Baker's March
SIGPLAN article. It deals with arbitrary data objects provided there are
descriptors. It never moves objects and may do its work when the system
is not busy. So far it looks great, any intrest.

-- 
cef@mwc.com        Mark Williams Co       Philosophy is the art of
708-291-6700 x119  60 Revere Drive        misunderstanding terms in a
708-291-6750 FAX   Northbrook, Il 60062   specialized language, designed
Charles (Froggy) Fiterman		  for that purpose.
Newsgroups: gnu.gcc.help
From: rfg@segfault.UUCP
Subject: Re: Conflicts between GCC and GLIBC -- What to do
Reply-To: lupine!segfault!rfg@uunet.uu.net
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 16:56:55 GMT


Roland McGrath writes:

     There is a potential problem with the `size_t' type and versions of
  GCC prior to release 2.4.  ANSI C requires that `size_t' always be an
  unsigned type.  For compatibility with existing systems' header files,
  GCC defines `size_t' in `stddef.h' to be whatever type the system's
  `sys/types.h' defines it to be.

That is all correct.

  Most Unix systems that define `size_t'
  in `sys/types.h', define it to be a signed type.

I don't believe that this is completely accurate.  Looking at the files in
the current development (pre-release) version of GCC 2.3, I see the following
definitions:

a29k.h:#define SIZE_TYPE "unsigned int"
convex.h:#define SIZE_TYPE "unsigned int"
dec-osf1.h:#define SIZE_TYPE    "long unsigned int"
decrose.h:#define SIZE_TYPE     "long unsigned int"
decstatn.h:#define SIZE_TYPE "unsigned int"
encrose.h:#define SIZE_TYPE     "long unsigned int"
hp320.h:#define SIZE_TYPE "unsigned int"
i386iscgas.h:#define SIZE_TYPE "unsigned int"
i386linux.h:#define SIZE_TYPE "unsigned int"
i386mach.h:#define SIZE_TYPE "long int"
i386sco.h:#define SIZE_TYPE "unsigned int"
i386sun.h:#define SIZE_TYPE "int"
iris.h:#define SIZE_TYPE        "unsigned int"
m88k.h:#define SIZE_TYPE "unsigned int"
mot3300.h:#define SIZE_TYPE "unsigned int"
news.h:#define SIZE_TYPE "long int"
news3.h:#define SIZE_TYPE "long int"
news3gas.h:#define SIZE_TYPE "long int"
pa-ghpux.h:#define SIZE_TYPE "unsigned int"
pa-hpux.h:#define SIZE_TYPE "unsigned int"
pa.h:#define SIZE_TYPE "unsigned int"
plexus.h:#define SIZE_TYPE int
romp.h:#define SIZE_TYPE "long int"
seq386.h:#define SIZE_TYPE "int"
sequent.h:#define SIZE_TYPE "int"
sparc.h:#define SIZE_TYPE "int"
sun2o4.h:#define SIZE_TYPE "int"
sun3.h:#define SIZE_TYPE "int"
svr3.h:#define SIZE_TYPE "unsigned int"
svr4.h:#define SIZE_TYPE "unsigned int"
ultrix.h:#define SIZE_TYPE "unsigned int"
vax-vms.h:#define SIZE_TYPE "unsigned int"
we32k.h:#define SIZE_TYPE "unsigned int"

Now I admit that this is not a "scientific" survey of all UNIX systems,
but it does make it appear that the majority of GCC target systems *are*
already conforming to the ANSI C standard with respect to the signedness
of size_t.  Only a few archaic systems do otherwise.


// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.
Newsgroups: gnu.gcc.help
From: av@omega.ssw.de (Andreas Vogel)
Subject: Re: glibc-1.04 installation problems
Date: Fri, 9 Oct 1992 10:30:00 GMT
Organization: Omega Softlab

In article <stephen.718321031@mont> stephen@mont.cs.missouri.edu (Stephen Montgomery-Smith) writes:
>In <1992Oct2.123803.20195@newsserver.rrzn.uni-hannover.de> muenkel@tnt.uni-hannover.de (Heiko Muenkel) writes:
>
>># make -w
>>make: Entering directory `/tmp_mnt/appl/gnu-source/glibc-1.04'
>>Makeconfig:72: extraneous text after `include'
>>make: sysdeps/..: Is a directory.  Stop.
>>make: Leaving directory `/tmp_mnt/appl/gnu-source/glibc-1.04'
>
>
>>Can anybody tell me what's going wrong ? 
>
>Could people tell me what is wrong too?  I get the same problem using
>sunos 4.1.1.
>

You have no chance to compile glibc without having make-3.62.19 (at least).
I can't understand why the developers of glibc don't give comments in any
README or INSTALL file, but the new (and not yet released) version of
make is a must in order to be sucessful.

After getting the new make, there haven't been any problems related to
the make stuff.

I've fetched make-3.62.19 from alpha.gnu.ai.mit.edu. But please remember, it
is not (yet) released.

-- 
Andreas Vogel                   Bahnhofstr. 13 / D-7300 Esslingen / Germany
				Voice:  +49-711/357613
				E-Mail: av@ssw.de
Newsgroups: gnu.gcc.help
From: tball@eo30.eoc.com (Tom Ball)
Subject: Wide character string support?
Summary: Does gcc support wide character strings?
Organization: EO, Inc.
Distribution: usa
Date: Tue, 13 Oct 1992 18:11:59 GMT

Our version of gcc 2.0 dies trying to parse wide character strings, as in
L"...".  Does any version of gcc support wide characters strings?  If so,
has anyone got a fix for the Sun version?  Thanks.

Tom Ball
EO, Inc.
From: james@unidata.com (James Powell)
Newsgroups: gnu.gcc.help
Subject: asdf
Date: 7 Oct 92 17:39:56 GMT
Distribution: gnu
Organization: Unidata, Inc.



--

/-----------------------------------------------------------------------------\
| James Powell - Programmer/Analyst - Special Projects - jamesp@unidata.com   |
\-----------------------------------------------------------------------------/
Xref: sparky gnu.gcc.announce:35 gnu.gcc.bug:2436 gnu.gcc.help:2268
From: roland@prep.ai.mit.edu (Roland McGrath)
Newsgroups: gnu.gcc.announce,gnu.gcc.bug,gnu.gcc.help
Subject: Conflicts between GCC and GLIBC -- What to do
Date: 6 Oct 92 22:52:12 GMT
Reply-To: bug-glibc@prep.ai.mit.edu
Followup-To: bug-glibc@prep.ai.mit.edu
X-Windows: You'd better sit down.
To: GNU C Library Bugs <bug-glibc@prep.ai.mit.edu>,
    GCC Bugs <bug-gcc@prep.ai.mit.edu>, help-gcc@prep.ai.mit.edu,
    GCC Announcements <info-gcc@prep.ai.mit.edu>

Some people have come across problems using the GNU C compiler (GCC) and
the GNU C library (glibc) together.  The following text is going into
glibc's INSTALL file, and explains the ways in which GCC and glibc don't
get along, and what to do about it, as of version 2.2.2 of GCC and version
1.05 of the GNU C library.

   The current release of the C library contains some header files that
the compiler normally provides: `stddef.h', `stdarg.h', and several
files with names of the form `va-MACHINE.h'.  The versions of these
files that came with older releases of GCC do not work properly with
the GNU C library.  The `stddef.h' file in release 2.2 and later of GCC
is correct.  If you have a new enough release of GCC, use its version
instead of the C library's.  To do this, put the line
`override stddef.h =' in `configparms'.  The other files are corrected
in release 2.3 and later of GCC.  If you have a new enough release of
GCC, use its files instead of the C library's.  To do this, put the
line `override stdarg.h =' in `configparms'.

   There is a potential problem with the `size_t' type and versions of
GCC prior to release 2.4.  ANSI C requires that `size_t' always be an
unsigned type.  For compatibility with existing systems' header files,
GCC defines `size_t' in `stddef.h' to be whatever type the system's
`sys/types.h' defines it to be.  Most Unix systems that define `size_t'
in `sys/types.h', define it to be a signed type.  Some code in the
library depends on `size_t' being an unsigned type, and will not work
correctly if it is signed.

   The GNU C library code which expects `size_t' to be unsigned is
correct.  The definition of `size_t' as a signed type is incorrect. We
plan that in version 2.4, GCC will always define `size_t' as an
unsigned type, and the `fixincludes' script will massage the system's
`sys/types.h' so as not to conflict with this.

   In the meantime, the way to work around this problem is to tell GCC
explicitly to use an unsigned type for `size_t' when you compile the
GNU C library.  You can do this by compiling with
`-D__SIZE_TYPE__='unsigned long int''.  You can either put this into
the GCC `specs' file to affect all compilations using GCC, or specify
the flag just to compile the C library, with this line in `configparms':

     # Be sure to remember the 's to quote the spaces from the shell.
     defines := -D__SIZE_TYPE__='unsigned long int'

When you do this, the current version of GCC will give you the annoying
warning:

     *Initialization*:1: warning: `__SIZE_TYPE__' redefined

It is safe to ignore this warning.  Version 2.3 of GCC is supposed to
fix this bug (the spurious warning--the type of `size_t' will not be
fixed until 2.4).
Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: read-only file suggestion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 23:33:03 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

A while back someone at Berkeley locally hacked Emacs so that when you
visited a file that was unwriteable or you used find-file-read-only,
Emacs automatically visited the file in View mode.

I thought this was a pretty neat idea.  I'm in favor of making
making this the default, but understand that it's a matter of taste.

Newsgroups: gnu.emacs.bug
From: gildea@expo.lcs.mit.edu (Stephen Gildea)
Subject: Re: mh-e sometimes does not send mail
Organization: X Consortium, MIT Laboratory for Computer Science
Distribution: gnu
Date: Fri, 9 Oct 1992 16:51:30 GMT

What version of MH are you running?  Please supply the output of
"send -help", not just a version number.

When the background send fails, what does "M-x list-processes" show?
Perhaps MH is still working, but just taking longer than you expected.

 < Stephen

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: tags-search should kill newly made buffers
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 23:51:27 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

Tags-search necessarily often visits a lot of unvisited files;
it should kill off the buffers for such files if it doesn't find the
searched-for string, before going on to the next file.

I just did a tags-search in a big source directory.  When the search
finished, I had 700 buffers and my Emacs process used 13 megs of memory.
Even just killing off the buffers made the machine page its brains out.
(I couldn't just exit Emacs and start a new one because I had a subprocess
running that I didn't want to kill).

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: Re: selective display bug
Organization: Boston University Computer Science Department
Distribution: gnu
Date: Sun, 11 Oct 1992 02:58:10 GMT

In article <9210020112.AA28170@napa.TELEBIT.COM> phr@napa.telebit.com (Paul Rubin) writes:

   C-x $ with no argument, disabling selective display, should not move
   the cursor.  For example, with selective display enabled, putting the
   cursor at an interesting question in the Emacs FAQ (etc/FAQ) and
   hitting C-x $ should display the answer along with the question.
   Instead, as it stands, both go way, way, off the screen.

Here is RMS's fixed version:

  (defun set-selective-display (arg)
    "Set selective-display to ARG; clear it if no arg.
  When selective-display is a number > 0,
  lines whose indentation is >= selective-display are not displayed.
  selective-display's value is separate for each buffer."
    (interactive "P")
    (if (eq selective-display t)
	(error "selective-display already in use for marked lines"))
    (let ((current-vpos
	   (save-restriction
	     (narrow-to-region (point-min) (point))
	     (goto-char (window-start))
	     (vertical-motion (window-height)))))
      (setq selective-display
	    (and arg (prefix-numeric-value arg)))
      (recenter current-vpos))
    (set-window-start (selected-window) (window-start (selected-window)))
    (princ "selective-display set to " t)
    (prin1 selective-display t)
    (princ "." t))

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: huxtable@kuhub.cc.ukans.edu (Kathryn Huxtable)
Subject: Problems with emacs on AIX 3.2
Organization: University of Kansas Academic Computing Services
Distribution: gnu
Date: Fri, 9 Oct 1992 19:43:47 GMT

We've been running emacs 18.57 with X-windows code on AIX
3.1 and we're upgrading to AIX 3.2 and we're noticing
strange problems under 3.2.

When I start emacs on a character cell terminal the first
character I type causes the message

    Fatal error (23).

to appear in the minibuffer, along with the character typed.
Further typing reveals that the terminal characteristics
haven't been set.  Characters are being echoed, input is
buffered up to newlines and ^C is an interrupt.

This doesn't happen 100% of the time but it happens a lot on
AIX 3.2 and we never noticed it on AIX 3.1.

I ftp'd emacs 18.58 from prep and recompiled using the
s-aix3.2.h file which just includes the 3.1 file.  This
didn't seem to affect the problem.

Does anyone know what's going on and how to fix it?

Running emacs in X-windows mode works just fine, of course....

Thanks for any suggestions or information.

-- 
Kathryn Huxtable              \   "Women who laugh too much, and the women
huxtable@kuhub.cc.ukans.edu   /\   who love them." --- Jamie Anderson

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: "cd" in shell mode should report errors
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 21:22:49 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

When change directories in a subshell, Emacs tries to notice, so
that find-file etc. do the right thing.  But if the current dir
has a subdir called "foobar-frobozz-pastafazoola" and I type
"cd foo*" to change into it, Emacs doesn't track it properly.
It is maybe too much to ask for Emacs to expand "foo*", but
if it tries to cd to "foo*" and fails, it should display
some message in the mode line saying that this has happened.
Then I can notice and do something about it if necessary.

Newsgroups: gnu.emacs.bug
From: jbw@cs.bu.edu (Joe Wells)
Subject: temp_echo_area_contents failing after message (Emacs 18.57)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 14:03:10 GMT

Emacs 18.57.

Problem 1.  The function temp_echo_area_contents fails after a message
when echo_area_contents != 0 or prev_echo_area_contents !=0.  The
equivalent function in Emacs 18.55, temp_minibuf_message, worked in this
situation.  To reproduce the problem, type this:

  C-x C-f jkl;asdf;jlk ?

And notice that the message " [No completions]" no longer shows up at the
end of the minibuffer text because the message "Making completion list..."
overrides it.

The fix is to insert these two lines in temp_echo_area_contents:

  echo_area_contents = 0;
  prev_echo_area_contents = 0;

Problem 2.  It is very hard to write your own completion routines that
display such messages after the minibuffer text because
temp_echo_area_contents is not accessible from Lisp.  Here is the code
that is currently necessary just to have the effect of clearing
echo_area_contents and prev_echo_area_contents:

      ;; The purpose is to set echo_area_contents = 0, so that the contents
      ;; of the minibuffer will show.
      ;; *** fix this so it doesn't assume RET exits minibuffer
      (let ((unread-command-char ?\C-m))
	(read-from-minibuffer "" nil nil nil))
      ;; This sets prev_echo_area_contents = echo_area_contents (which is 0)
      ;; *** fix this so it doesn't assume RET exits minibuffer
      (let ((unread-command-char help-char)
	    (help-form '(setq unread-command-char ?\C-m)))
	(read-key-sequence nil))

As you can easily tell, this is a gross, disgusting hack that is likely to
fail in future versions of Emacs.  The fix for this is to make
temp_echo_area_contents work, and make it accessible from Lisp.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: sra@epilogue.com (Rob Austein)
Subject: tags-search should kill newly made buffers
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 21:12:18 GMT

   Date: 14 Oct 92 23:51:27 GMT
   From: phr@napa.telebit.com (Paul Rubin)

   Tags-search necessarily often visits a lot of unvisited files;
   it should kill off the buffers for such files if it doesn't find the
   searched-for string, before going on to the next file.

Sounds like the way tags-search worked in the old TECO emacs where
memory space was at a premium.  Unless you set Q$Tags Find File$ to
some magic value that now escapes me, it did MM Visit File$ in a
buffer called *Tags Search* instead of doing MM Find File$.

If your change is implemented it should be an option, not mandatory
behavior.  If you've never tried running tags-search via ange-ftp to a
machine on the other side of the country, just take my word for it,
you do *not* want to flush all those buffers after just one use.

--Rob Austein <sra@epilogue.com>

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: buffer menu mode suggestion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 23:43:50 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

Typing "0" with the cursor on a line in the buffer list
should select that buffer, displaying it where the buffer
list used to be, but not affect the contents of any of the other
windows on the screen.  "1" completely deletes all the other
windows and "2" seems to display the buffer you select along
with another random one---I've never intuitively understood
what it does.  "0" is sort of analogous with C-x 0.

Newsgroups: gnu.emacs.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: c-mode indentation doesn't do `do ... while' right.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 09:28:45 GMT

Put the following text in a buffer in c-mode, and do C-M-q.

{
  if (cond)
    do
      stmt;
    while (cond);
}

It becomes:

{
  if (cond)
    do
      stmt;
  while (cond);
}

It wins if you put curly braces around the do...while statement.



Newsgroups: gnu.emacs.bug
From: macrakis@osf.ORG (Stavros Macrakis)
Subject: sort "foo"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 12:00:36 GMT

Epoch 4.0.1 of Tue Jul 21 1992 on phoenix (aix-v3)

(sort "foo" '<) appears to go into an infinite loop.  It should either
give an error or sort the sequence.

	-s

Newsgroups: gnu.emacs.bug
From: keith%accura_nc@concert.net (Keith B. Kee {AISG} )
Subject: Problem with compile
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 19:38:07 GMT

Hi:
 I notice that when I compile a C++ program in emacs, emacs will read the 
.cshrc first before it compiles. However, it did not read the environment
variables from the current shell. Take for instance, I define 
AIEHOME to be /proj/AIE and in the interative shell I redefine the AIEHOME
to be /proj/AUC. Then I invoke emacs, and compiles a program within emacs.
The AIEHOME is set to /proj/AIE instead of /proj/AUC. 

-Keith

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: record_buffer should be an Emacs Lisp function
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 21:41:09 GMT

The function record_buffer in buffer.c should be callable from Lisp.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: desj@idacrd.UUCP (David desJardins)
Subject: Documentation bug for edit-picture-hook
Organization: IDA Center for Communications Research, Princeton
Distribution: gnu
Date: Sun, 11 Oct 1992 03:45:36 GMT

The manual and info node for Picture mode say that the variable
'picture-mode-hook' is called on entering Picture mode.  As far as I can
tell, this variable does not exist and is not used for anything.  The
hook actually used by Picture mode is 'edit-picture-hook'.

I am using GNU Emacs version 18.58.

                                        David desJardins

Newsgroups: gnu.emacs.bug
From: smg@surf.cis.ufl.edu (Scot M. Gardner)
Subject: Re: mh-e sometimes does not send mail
Reply-To: Scot Gardner <smg@cis.ufl.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:20:48 GMT

In sound mind and body you, Stephen Gildea <gildea@expo.lcs.mit.edu>, wrote: 
> What version of MH are you running?  Please supply the output of
> "send -help", not just a version number.
> 
First of all, thanks for your assistance Stephen.

Here is the output to the send -help command:

syntax: send [file] [switches]
  switches are:
  -alias aliasfile
  -draft
  -(draftf)older +folder
  -(draftm)essage msg
  -nodraftfolder
  -filter filterfile
  -nofilter
  -[no]format
  -[no]forward
  -[no]msgid
  -[no]push
  -[no]verbose
  -[no]watch
  -width columns
  -(help)

version: MH 6.7.1 #57[UCI] (beach) of Thu Aug 6 11:58:54 EDT 1992
options: [ATZ] [ATHENA] [BERK] [BIND] [BSD42] [BSD43] [SUN40] [DUMB]
         [DBM] [MHE] [NFS] [NETWORK] [RPATHS] [MHRC] [MSGPROT='"0600"']
         [SBACKUP='"#"'] [TYPESIG='void'] [RPOP] [POP2] [AUTOPOP]
         [POPSERVICE='"pop3"'] [SENDMTS] [POP]
 
> When the background send fails, what does "M-x list-processes" show?
> Perhaps MH is still working, but just taking longer than you expected.

I sent mail until a message did not get sent. When I checked my process
list it was blank (execpt for the process I use to show the time). The
draft was still sitting in drafts folder. 

> 
>  < Stephen
|Scot Gardner Inet: smg@cis.ufl.edu UUCP: ...!gatech!uflorida!smg             |
|"Warning, For external use only. If taken internaly severe gastric           |
| disturbance will result"                                                    |

Newsgroups: gnu.emacs.bug