vance@mtxinu.UUCP (Vance Vaughan) (11/07/84)
4.2 BUGLIST ABSTRACTS from MT XINU, part 4 of 10:
The following is part of the 4.2 buglist abstracts as processed by
Mt Xinu. The initial line of each abstract gives the offending
program or source file and source directory (separated by --),
who submitted the bug, when, and whether or not it contained
a proposed fix. Due to license restrictions, no source is
included in these abstracts.
Important general information and disclaimers about this and
other lists is appended at the end of the list...
lib.b--usr.lib Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX
The bc library lib.b was missing from our 4.1c tape.
I was bummed because I wanted to see if you had fixed
a bug we found in 4.1a. In case you missed that one,
here it is again:
All calls to a(x) (except a(0)) return same value because
in /usr/lib/lib.b:
-----
if(x==1)
if(scale<52)
return(.7853981633974483096156608458198757210492923498437764/1)
-----
should be:
-----
if(x==1) {
if(scale<52) {
return(.7853981633974483096156608458198757210492923498437764/1)
}
}
REPEAT BY:
N/A
FIX:
I retrieved it from our 4.1a system
_______________________________________________________________________________
libI77--usr.lib Pisces Development <pisces@Fuji> 1 Oct 84
According to /usr/doc/f77/f77IO.ms, "a real value that is zero
will display as 0. to distinguish it from a very small non-zero
value. This occurs in F and G format conversions. This was not
done for E and D since the embedded blanks in the external
datum causes problems for other input systems."
It WAS done for E and D, causing problems for this and
other input systems.
REPEAT BY:
Compile and run the following Fortran program:
-----------------------------
write(6,'(1pe12.3)') 0.,1.,2.
stop
end
-----------------------------
Output on Fuji@Stanford (4.2BSD) is
0. e+00
1.000e+00
2.000e+00
If this is piped into:
read(6,*) a,b,c
a gets 0, b gets 0, c gets 1.
From: C.S.Rafferty, 231A Applied Electronics Laboratory, Via Crespi,
Stanford Ca.94305
_______________________________________________________________________________
libI77--lib dlw@ucbopal.CC (David L Wasley) 6 Jun 84 +FIX
This is my mistake: the routines ioinit.o & ioinit.f should be
in libU77.a and not in libI77.a
This is because they are essentially user code and refer to
entry points in the other libs.
Repeat by:
I believe if you just call ioinit and nothing else, the load
will fail, eg:
program x
call ioinit()
end
FIX:
Move ioinit source to libU77, modify the makefile appropriately
in both directories, and remake both libs.
_______________________________________________________________________________
libI77/err.c--usr.lib dlw@ucbopal.CC (David L. Wasley) 28 Oct 83 +FIX
FORTRAN programs will not core dump after an error has been detected.
REPEAT BY:
program test
C
write (6, 10) i
stop
10 format (1^)
end
_______________________________________________________________________________
libI77/ioinit.f--usr.lib sdcsvax!sdchema!donn 23 Feb 84 +FIX
The new F77 I/O library routine ioinit() is very useful but
unfortunately it has the problem that it wants to use
subroutines from the run-time library, and the run-time
library is loaded ahead of the I/O library.
REPEAT BY:
If you compile the program 'iotest.f' as in the script below,
you get the results shown:
----------------------------------------------------------------
% cat iotest.f
c
c iotest.f -- check load order of ioinit()
c
logical n
logical ioinit
n = ioinit( .true., .false., .false., 'FORT', .false. )
stop
end
% f77 -O iotest.f
iotest.f:
MAIN:
Undefined:
_i_len
_i_indx
_lnblnk_
_s_cmp
_s_copy
%
----------------------------------------------------------------
More complex programs probably don't have this problem -- they
load all of the routines needed by ioinit() anyway, because
they need them elsewhere. However a reasonably complex program
which one of our users was trying to bring up still failed to
load a few of the required routines.
FIX:
I scratched my head with this one. I have decided not to offer
a real fix and let the authorities decide how to deal with it.
There are a number of conceptual problems (e.g, ioinit.f is
supposed to be a model F77 subroutine, but it won't work in the
F77 I/O library because it calls run-time subroutines like any
good F77 program should, so perhaps it should be rewritten in
C; or perhaps the run-time and I/O libraries should get loaded
together; etc.). A hack that makes the problem go away is the
following:
----------------------------------------------------------------
# cd /usr/lib
# ar xv libI77.a ioinit.o
x - ioinit.o
# ar rv libF77.a ioinit.o
a - ioinit.o
# ranlib libF77.a
# rm ioinit.o
----------------------------------------------------------------
Donn Seeley UCSD Chemistry Dept. ucbvax!sdcsvax!sdchema!donn
32 52' 30"N 117 14' 25"W (619) 452-4016 sdcsvax!sdchema!donn@noscvax
_______________________________________________________________________________
libI77/sfe.c--usr.lib dlw@ucbopal.CC (David L. Wasley) 30 Oct 83 +FIX
(Original description, submitted 26 Oct 83, by gregc@ucsfcgl.UUCP)
"Formatted read's with X's don't behave properly on truncated lines."
Actually, the format execution IS correct. However, the I/O system
should be tolerant and allow short records, particularly if a human
is typing data. Therefore, the "1x" below should not cause an error.
REPEAT BY:
Try the program below, and type in lines that are 3 characters
long and those that are longer. A 3 character line causes a
F_EREREC error.
C
C Exercise read from incomplete line bug
C
program test
C
character*3 str
integer int
real float
C
read (5, 10) str, int, float
print *, str
stop
10 format (a3,1x,i7,f8)
end
FIX:
The original fix proposed introduces other bugs as side effects.
The fix below works only for sequential external reads from a
device that can't seek, e.g. a terminal port. The more general
fix requires major restructuring of the I/O code.
I've delta'ed this into the source code on UcbMonet.
diff sfe.c version 1.7 vs version 1.8
170c170
< if(n=='\n') return(F_EREREC);
---
> if(n=='\n') return(cursor=0); /* be tolerant */
David Wasley
dlw@opal.CC.Berkeley
_______________________________________________________________________________
lib[FU]77/signal_.c--usr.lib quarles@ucbic (Tom Quarles) 13 Oct 83 +FIX
The user accessable signal handling mechanism provided in both
libF77 and libU77 (source is identical except for sccsid) is
for the old signal system, and does not allow access to signals
from 16 to 27, and more importantly, does not pass on the
additional fields now supplied, most importantly, the signal
code field which distinguishes betweeh the different types of
floating point exceptions.
REPEAT BY:
Comparing the source code with the documentation.
_______________________________________________________________________________
libc/gen/alarm.c--lib sun!shannon (Bill Shannon) 21 Mar 84 +FIX
alarm (which is implemented using setitimer) can sometimes lie
and return zero even when there is an alarm pending. This
screws up people who do:
left = alarm(0); /* turn alarm off */
diddle, diddle, diddle...
alarm(left); /* turn it back on */
REPEAT BY:
See above.
_______________________________________________________________________________
libc/gen/crypt.c--lib cooper (Eric Cooper) 9 Oct 83 +FIX
The primitive DES function encrypt() doesn't work if you call it
directly. For instance, if you encrypt something and then decrypt it,
you don't get what you started with.
REPEAT BY:
/*
* Test DES by encrypting block of all 1's with 0 key.
*/
char key[64];
char data[64];
main()
{
register int i;
for (i = 0; i < 64; i++)
data[i] = 1;
setkey(key);
encrypt(data, 0);
encrypt(data, 1);
/* data should again be all 1's, but isn't */
for (i = 0; i < 64; i++)
printf("%d", data[i]);
printf("\n");
}
FIX:
The problem is that there are two arrays, e[], which is initialized,
and E[], which isn't. As it stands now, E[] only gets set in crypt(),
the higher-level password encryption function. There's a for-loop in the
code for crypt() which copies e[] to E[]. (Later on, E gets shuffled around.)
The fix is to take this for-loop out of crypt() and put it in setkey(),
so that E[] will get set up even if you don't go through crypt().
_______________________________________________________________________________
libc/gen/crypt.c--lib amd!nsc!chongo (Landon C. Noll) 22 Sep 84 +FIX
Encryption/Decryption via the encrypt(3)/setkey(3) system does
not work. The reason for this problem is that the E table
is not setup prior to use. Worse, crypt(3) loads the E table
with the standard values and then perturbs the E table. Calling
crypt(3) between usage of encrypt(3) changes the E table.
REPEAT BY:
The following program with fix undefined will show the error
with the standard crypt.c. When you have applied the bug fix
and installed the new crypt.c in libc.a, recompile with -Dfix.
--------------------------cut here for crypttest.c-----------------------------
/*
* play with DES encryption
*
* usage:
* crypttest key block
*
* adopted from a program by: ihnp4!ihnet!tjr
*
* NOTE: when the fix is made to the crypt(3) routines, define fix and
* recompile.
*/
#include <stdio.h>
main(argc,argv)
int argc;
char *argv[];
{
register i; /* index */
char *crypt();
char block[65]; /* block to encrypt */
char block2[65]; /* copy of block */
char key[64]; /* key to encrypt by */
/* arg check */
if(argc != 3)
fprintf(stderr,"usage: %s key text\n",argv[0]);
/* convert key to a binary bit per byte */
for( i=1; i<64; ++i) {
/* make the extra bits zero */
if ( ! argv[1][i-1] ) {
for ( ; i<64; ++i ) {
key[i] = 0;
}
break;
} else if ( argv[1][i-1] == '0' ) {
key[i] = 0;
} else {
key[i] = 1;
}
}
/* convert block to a binary bit per byte */
for( i=1; i<64; ++i) {
/* make the extra bits zero */
if ( ! argv[2][i-1] ) {
for ( ; i<64; ++i ) {
block[i] = 0;
block2[i] = 0;
}
break;
} else if ( argv[2][i-1] == '0' ) {
block[i] = 0;
block2[i] = 0;
} else {
block[i] = 1;
block2[i] = 1;
}
}
/* set our key */
setkey(key);
#ifdef fix
load_etable(0); /* preload the standard E table */
#endif fix
/* show what we start with */
#ifdef fix
printf("We will encrypt and decrypt back to the original\n\n");
#else
printf("In this test, we shall encrypt/decrypt with encrypt(3).\n");
printf("Note that we dont get the original back!\n\n");
#endif fix
prt("original: ",block);
/* encrypt it */
encrypt(block,0);
prt("encrypted: ",block);
/* decrypt */
encrypt(block,1);
prt("original: ",block);
/* encrypt it again */
putchar('\n');
#ifdef fix
printf("\nUsing crypt(3) does not change things\n\n");
#else
printf("\nNext we will use crypt(3) and reload our key. You will\n");
printf("observe that crypt(3) disturbs encrypt(3)\n\n");
#endif fix
prt("original: ",block2);
encrypt(block2,0);
prt("encrypted: ",block2);
/* now we use crypt and reset the key afterwards */
crypt(block,"aA");
setkey(key);
/* decrypt */
encrypt(block2,1);
prt("original: ",block2);
}
prt(s,block)
char *s;
char block[];
{
int i;
fputs(s,stdout);
for(i=1; i<64; ++i)
putchar(block[i]+'0');
putchar('\n');
}
--------------------------end of crypttest.c-----------------------------
_______________________________________________________________________________
libc/gen/ctime.c--lib solomon@wisc-crys (Marvin Solomon) 4 Jan 84 +FIX
localtime() (and hence ctime()) returns a ridiculous result when handed
an input representing a moment between midnight, Jan 1, 1970 local
time and midnight, Jan 1, 1970 GMT. In particular, they return nonsense
on an input of 0.
REPEAT BY:
compile and run the program:
main() {
int t = 0;
printf(ctime(&t));
}
_______________________________________________________________________________
libc/gen/ctime.c--lib ECN.davy@Purdue.ARPA (Dave Curry) 25 Aug 84 +FIX
The asctime() routine will die on dates after Dec 31 23:59:59 1999,
producing a string with an incomplete year.
REPEAT BY:
#include <sys/time.h>
main()
{
char *ctime();
long clock = 946702800; /* or anything greater */
printf("Next line should be: Sat Jan 1 00:00:00 2000\n");
printf("%s", ctime(&clock));
}
FIX:
On line 292, change:
cp[2] = '0' + t->tm_year >= 200;
to:
cp[2] = '0';
--Dave Curry
decvax!pur-ee!davy
eevax.davy@purdue
_______________________________________________________________________________
libc/gen/ctype_.c--lib hpda!hpdsa!decot (Dave Decot) 4 Sep 84 +FIX
Manual page seems to indicate that anything less than ' ' will
return non-zero from iscntrl(). The "space characters" (HT,
LF, VT, FF, CR) are classified as space but not as control.
REPEAT BY:
main() {
printf("Is \\n a control character? %s\n", iscntrl('\n')? "Yes" : "No");
}
FIX:
Change "_S" to "_S|_C" for those five characters in the table, or
fix the manual.
Dave Decot
_______________________________________________________________________________
libc/gen/execvp.c--lib donn@utah-cs (Donn Seeley) 16 Oct 84 +FIX
It seems to me that this has been complained about before, but
since it doesn't appear to have been fixed (I just peeked on
monet), I figure I might as well submit a report. The problem
is that execvp() treats '-' as separating paths in a PATH
variable, unlike the shell. This causes many surprises when
'make' wants to find commands in directories that have
hyphenated names (as I just discovered) and probably has other
negative side-effects.
REPEAT BY:
% mkdir /tmp/a-test
% cp /bin/echo /tmp/a-test/a-echo
% setenv PATH /tmp/a-test:$PATH
% cat > makefile
hi:
a-echo hi there
% make hi
a-echo hi there
Make: Cannot load a-echo. Stop.
%
_______________________________________________________________________________
libc/gen/frexp.c--lib Jeff Mogul <mogul@Gregorio> 16 Aug 84 +FIX
The manual page for frexp(3) states that it ``returns the mantissa
... as a double ... of magnitude less than 1''. In fact, it does
not always do this: if the input is a power of two, the value
returned is equal to 1, not less than 1.
Also, if the input is zero, then the function goes into an infinite
loop.
The first problem can be solved either by changing the manual
page or by fixing the function. The second problem is obviously
a bug.
REPEAT BY:
Compile this program:
double frexp();
main()
{
double value;
double mantissa;
int exponent;
while (1) {
scanf("%lf",&value);
mantissa = frexp(value, &exponent);
printf("%f == %f * 2^%d\n", value, mantissa, exponent);
}
}
and run it with the input:
1.0
2.0
0.0
It will print:
1.000000 == 1.000000 * 2^0
2.000000 == 1.000000 * 2^1
and then hang
_______________________________________________________________________________
libc/gen/frexp.c--lib Mike Muuss <mike@BRL-VGR.ARPA> 22 Aug 84 +FIX
When executing a program that uses sqrt() heavily, more time
is spent in frexp() (called by sqrt()) than in sqrt() itself!
frexp() just returns the fractional & exponent parts of a
floating point number. It's problem is that it's written
in a nice machine independent manner which is quite portable,
but also foolish and slow.
Also, frexp( 1.0, &i ) will return a fractional part of 1.0
and an exponent of 0, even though the documentation explicitly
states that the return is LESS THAN 1.0 -- I have fixed this
problem in both the vax and !vax code, below.
REPEAT BY:
Write a program to use sqrt() a lot. Profile it with -pg -lm_p
and count the cycles.
_______________________________________________________________________________
libc/gen/getwd.c--lib Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX
If you have a soft link pointing at a directory on which you
mount a file system, getwd will often return a path starting
at that link, rather than at the real directory.
(Well, hey, our users got confused!)
REPEAT BY:
Make a soft link in / which points at a directory on which a file
system is mounted. Cd to a subdirectory in the file system, and
do a pwd. Note: this happens only if the soft link happened to
get into the directory earlier than the real directory name (or
maybe it's the inode being smaller).
_______________________________________________________________________________
libc/gen/malloc.c--lib lepreau@utah-cs (Jay Lepreau) 9 Nov 83 +FIX
1. When RCHECK is defined, realloc needs to move the trailing
RMAGIC and adjust the recorded ov_size when it uses the same
block. Otherwise got false assertion failures. Spencer Thomas
found this one.
2. botch() printout needs cleaning up: it used to print to
stdout and w/o an fflush (so never saw it), and it needs to bracket
the msg with \r\n's cause terminal state may be funny.
3. If one defined RCHECK but not debug you didn't get any checking.
4. minor lint in morecore().
(5. There seems to be some redundant code in morecore(), i.e.
"can't happen" stuff, but why mess with working code?)
REPEAT BY:
Inspection (these arose in Gosling's emacs for us).
_______________________________________________________________________________
libc/gen/mktemp.c--lib Keith Bostic <keith@seismo.ARPA> 25 Sep 84 +FIX
1: Mktemp only produces 26 unique file names.
It's a real pain to run out of file names,
especially considering...
2: On failure, mktemp returns the string "/".
You can't test mktemp in the standard fashion, i.e.
"if (!mktemp(str))" has to be done as
"if (!strcmp(mktemp(str),"/"))" unless you just want
to try and recover when you fail to open the file. The
fact that it returns "/" is undocumented, and a real
good 20 minute bug when it occurs.
REPEAT BY:
#include <stdio.h>
main()
{
int cnt;
char buf[20],
*strcpy(), *mktemp();
for (cnt = 0;cnt < 30;++cnt) {
creat(mktemp(strcpy(buf,"/tmp/fileXXXXXX")),0444);
printf("%d -- %s\n",cnt,buf);
}
}
_______________________________________________________________________________
libc/gen/popen.c--lib dlw@ucbmonet (David Wasley) 12 Aug 83 +FIX
Popen() unconditionally dup2's the child's end of the pipe
after forking. It then closes the original. If the fd was
already correct, it ends up with NO fd!
REPEAT BY:
Run the following with & without an arg.
#include <stdio.h>
main(argc)
{
if (argc < 2)
close(0);
fprintf(popen("/bin/cat", "w"), "hello cat\n");
}
_______________________________________________________________________________
libc/gen/random.c--lib jerry@ucbopal.CC (Jerry Berkman) 13 Sep 84
According to man 3 random:
"random will by default produce a sequence of numbers
that can be duplicated by calling srandom with 1 as the seed"
The following program shows this does not always work.
It reinitializes each time it calls random() and therefore should
always print the same number, but it does not.
REPEAT BY:
#include <stdio.h>
main()
{
int i;
for (i = 1; i < 20; i++ ) {
srandom(1);
printf("%12d\n", random(0));
}
}
_______________________________________________________________________________
libc/gen/scandir.c--lib Jay Lepreau <lepreau@utah-cs> 29 Nov 83 +FIX
1. If the arraysz estimate proved low, scandir does a realloc
assuming the worst, but it never recomputes the new arraysz,
so it keeps calling realloc all the rest of the way thru the dir.
(This isn't as bad as it sounds, for realloc is smart enuf not
to do anything if the same size is requested.)
2. scandir is overly optimistic about the worst case: the directory
could grow on it (unless there's some synchrony out there I don't
know about), leading to an infinite loop. It should restat the
directory.
REPEAT BY:
Well, *I* noticed it from that nifty gprof output showing
hundreds of realloc calls. Obvious from inspection too.
_______________________________________________________________________________
libc/gen/sleep.c--lib pur-ee!ef:ks (Kirk Smith) 27 Aug 84 +FIX
After a call to sleep(), the signal SIGALRM remains blocked.
REPEAT BY:
main()
{
sleep(1);
alarm(1);
}
This program will never terminate.
_______________________________________________________________________________
libc/gen/syslog.c--lib Marshall Rose <mrose@uci-750a> 18 Jan 84 +FIX
If the format string you give to syslog() contains a '%' escape
other than a '%m', then the format string is truncated after that
escape and the resulting output in the syslog file looks very wierd.
This bug makes syslog() virtually useless if you like to put lots
of information in a single line.
REPEAT BY:
Run the following program, wait a while for some other process to send
something to the syslog daemon, and then check out the file.
You'll see something like this:
Jan 17 17:39:12 localhost: 4222 foo: argc=1<8>4231 sendmail: connected to uci-750b
Note how the syslog daemon got real confused on that one...
#include <syslog.h>
main (argc, argv)
char **argv;
{
openlog ("foo", LOG_PID);
syslog (LOG_INFO, "argc=%d *argv=%s", argc, *argv);
}
_______________________________________________________________________________
libc/gen/ttyslot.c--lib watcgl!dmmartindale 28 Mar 84 +FIX
The ttyslot() C library routine is called by many programs
(either directly or via getlogin()) because it reads through
/etc/ttys via sys reads of one byte. On a large system, this
wastes an appreciable amount of time.
REPEAT BY:
On a completely unloaded system, type "su". See how long it
takes to prompt for a password. On watmath, su took 1.5 CPU
seconds to reach this point, when invoked from a pseudo-tty
line whose entry is near the end of /etc/ttys. 1.39 seconds
of this was spent in sys read called from getttys().
(Gprof is wonderful!)
_______________________________________________________________________________
libc/stdio/fopen.c--lib ralph (Ralph Campbell) 25 May 83 +FIX
I think I might have found a bug in the 4.1bsd fopen routine.
At the start of stdio/fopen.c, the following code appears:
for (iop = _iob; iop->_flag&(_IOREAD|_IOWRT|_IORW); iop++)
if (iop >= _lastbuf)
return(NULL);
The purpose of this segment is apparently to find an unused element
of the iob array. The problem with this is that it's possible
to exit the loop with iop == _lastbuf, which should never happen.
When it does, a variety of program malfunctions can occur, based
on what lies after the last element of _iob.
REPEAT BY:
When I was trying to find this bug, I was using adb (and sdb). When
I ran the program with adb, the program worked ok. When I just ran
the program, it blew up. It seems like I've had this (programs not
being buggy inside a debugger) happen before, does anybody know
any general causes of this phenomenon?
_______________________________________________________________________________
libc/stdio/fputs.c--lib Mike Braca <mjb%Brown@UDel-Relay> 27 Sep 83 +FIX
Fputs returns garbage when passed a zero-length string. It should
return 0 instead.
REPEAT BY:
Obvious (just look at the source)
FIX:
change the declaration:
register r;
to:
register r = 0;
_______________________________________________________________________________
libc/vax/gen/bcopy.s--lib lepreau@utah-cs (Jay Lepreau) 7 Sep 83 +FIX
The one line comment at the tops says:
/* bcopy(to, from, size) */
but the man page says bcopy(b1, b2, len) copies from b1 to b2.
The man page is right (unfortunately for compatibility).
REPEAT BY:
Yikes! Scenario: 1) not able to find the man page and so glance at
source, 2) surprised and grateful that there is such a comment there,
3) pgm gets blown away, 4) much later really look at the source...
FIX:
No, it's NOT to delete the comment....
_______________________________________________________________________________
libc/vax/gen/ffs.s--lib donn@utah-cs (Donn Seeley) 17 Sep 84 +FIX
The documentation for ffs() says it returns -1 if 0 is passed
as an argument, but in fact it returns 0.
REPEAT BY:
Compile the following program:
----------------------------------------------------------------
main()
{
register int i, j;
for ( i = -1; i < 32; ++i ) {
j = (i < 0 ? 0 : 1 << i);
printf( "%#010x : %d\n", j, ffs( j ) );
}
}
----------------------------------------------------------------
When run it prints:
----------------------------------------------------------------
0000000000 : 0
0x00000001 : 1
0x00000002 : 2
0x00000004 : 3
0x00000008 : 4
0x00000010 : 5
0x00000020 : 6
0x00000040 : 7
...
----------------------------------------------------------------
Notice the misfeature of printf() that prevents zero operands
from being converted the same way as other operands with "%#x"...
What is the point of that?
FIX:
It's pretty clear to me that the documentation is wrong. The
following trivial change in man3/ffs.3 would make it correspond
properly with the actual function return values:
----------------------------------------------------------------
< starting at 1. A return value of \-1 indicates the
---
> starting at 1. A return value of 0 indicates the
----------------------------------------------------------------
The Sun documentation fixed one problem ('starting at 1' now
reads 'starting at 1 from the right') but the '-1' is still
there (and is wrong for the Sun, too, from what I can tell).
If the function is wrong, I'd be very surprised,
Donn Seeley University of Utah CS Dept donn@utah-cs.arpa
40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
_______________________________________________________________________________
libdbm/Makefile--usr.lib sjk@sri-spam (Scott J. Kramer) 11 Nov 83 +FIX
The "-c" option should be used when compiling the dbm library
and the resulting object should be renamed to libdbm.a.
REPEAT BY:
Run "make" in the source directory.
FIX:
Fix the makefile...
RCS file: Makefile,v
retrieving revision 4.2
diff -r4.2 Makefile
1a2
> # $Header: Makefile,v 4.2.1.1 83/11/11 22:04:32 sjk Exp $
3c4
< CFLAGS=-O
---
> CFLAGS=-O -c
7c8,9
< ${CC} -o libdbm.a ${CFLAGS} dbm.c
---
> ${CC} ${CFLAGS} dbm.c
> @mv dbm.o libdbm.a
_______________________________________________________________________________
libplot--usr.lib sun!shannon (Bill Shannon) 5 Sep 83 +FIX
The plot libraries for 300, 300s, 450, and 4014 are named
libt300.a, libt300s.a, etc. instead of lib300.a, etc. The
plot filters in /usr/src/usr.bin/plot use -l300, etc.
FIX:
Change the Makefile, the directory names (t300 to 300, etc.)
and the Makefiles in the directories to use the proper names.
Bill Shannon
sun!shannon
Sun Microsystems, Inc.
_______________________________________________________________________________
lint--usr.bin allegra!rdg Jul 4 83
lint fails to detect the use of an assignment statement
which reduces to a constant as the conditional in an if
statement.
with the -h lint option, statements like
if (1)
foo();
produce the warning "constant in conditional statement".
unfortuantely, the statement if (a = 1) which is just
as much a "constant" does not produce the warning.
This is definitely a bug in lint, no question about it!
REPEAT BY:
lint -h file.c
where file.c contains
main()
{
int a;
if (a = 1)
x();
}
_______________________________________________________________________________
lint--usr.bin ellis @ tektronix Jun 20 83 +FIX
According to the man page for lint, flag options can be concatenated
together (that is, "lint -ab file ..." works). The shell script in
/usr/bin/lint uses a case statement to process flags. However,
the command invocation
lint -I/usr/joe/include ...
"breaks" the script. The check for the "-n" option flag is made by
checking for "-*n*"; therefore, as a side-effect of specifying this
particular -I flag, the standard library compatibility checks are
disabled (resulting in large numbers of erroneous lint messages).
A simple fix is to change the script from
-*n*) P= ;;
-*p*) P=port ;;
to
-n) P= ;;
-p) P=port ;;
which simply requires the use of "-n" or "-p" to occur separately
(which the shell script permits, anyway).
_______________________________________________________________________________
lint--usr.bin mazama!stew (Stewart Levin) 29 Apr 84
static declarations appearing in #include files and used
later on in the source file that #include'ed them cause
lint to complain that (1) the variable is defined
but not used in the #include file and (2) the variable
is used but not defined in the source file.
The same program, when compiled executes properly.
It seems lint restricts static declarations to within
the actual file in which they appear (i.e. the #include file)
rather than the more liberal interpretation of any source
file that includes the declaration.
REPEAT BY:
Include file "pi.h":
static double pi=3.1415926535;
Source file "bug.c":
#include "pi.h"
main()
{
printf("2pi=%f\n",2.0*pi);
}
Command:
lint -lc bug.c
Result:
bug.c:
pi defined( ./pi.h(1) ), but never used
pi used( bug.c(4) ), but not defined
_______________________________________________________________________________
lint--usr.bin ellis @ tektronix Jun 20 83 +FIX
According to the man page for lint, flag options can be concatenated
together (that is, "lint -ab file ..." works). The shell script in
/usr/bin/lint uses a case statement to process flags. However,
the command invocation
lint -I/usr/joe/include ...
"breaks" the script. The check for the "-n" option flag is made by
checking for "-*n*"; therefore, as a side-effect of specifying this
particular -I flag, the standard library compatibility checks are
disabled (resulting in large numbers of erroneous lint messages).
A simple fix is to change the script from
-*n*) P= ;;
-*p*) P=port ;;
to
-n) P= ;;
-p) P=port ;;
which simply requires the use of "-n" or "-p" to occur separately
(which the shell script permits, anyway).
_______________________________________________________________________________
lint/llib-lc--usr.bin ucsfcgl!blia!eric (Eric Allman) 9 Feb 84 +FIX
The declaration of longjmp shows the environment as "*e" instead
of "e".
REPEAT BY:
Lint something that uses longjmp -- extra errors will be generated.
FIX:
Remove the extra * from the declaration and remake.
_______________________________________________________________________________
lisp--ucb Dove <dove@sylvester> 25 Feb 84
Franz lisp gets in a cycle in macroexpansion for certain forms of
the mit loop macro. These constructions work fine on my 3600.
REPEAT BY:
--
-> (trace macroexpand)
-> (macroexpand '(loop for i = (ncons 0)
for j from 0 do
collecting (list i j)))
1 <Enter> macroexpand ((loop for i = (ncons 0) ...))
|2 <Enter> macroexpand ((ncons 0))
| 3 <Enter> macroexpand (0)
| 3 <EXIT> macroexpand 0
|2 <EXIT> macroexpand (ncons 0)
|2 <Enter> macroexpand ((ncons 0))
| 3 <Enter> macroexpand (0)
| 3 <EXIT> macroexpand 0
|2 <EXIT> macroexpand (ncons 0)
|2 <Enter> macroexpand ((ncons 0))
| 3 <Enter> macroexpand (0)
| 3 <EXIT> macroexpand 0
|2 <EXIT> macroexpand (ncons 0)
|2 <Enter> macroexpand ((ncons 0))
| 3 <Enter> macroexpand (0)
| 3 <EXIT> macroexpand 0
|2 <EXIT> macroexpand (ncons 0)
|2 <Enter> macroexpand ((ncons 0))
| 3 <Enter> macroexpand (0)
| 3 <EXIT> macroexpand 0
|2 <EXIT> macroexpand (ncons 0)
|2 <Enter> macroexpand ((ncons 0))
Interrupt:
Break nil
<1>: Interrupt:
Break nil
<2>:
<1>:
[Return to top level]
->
------
Please send me an immediate reply if this problem is fixed already, I am
under great time pressure.
_______________________________________________________________________________
lisp--ucb jbn@FORD-WDL1.ARPA 1 Mar 84
There are definitions of DEFCONST in both machacks.l and loop.l, and
they are different. If a LOOP call appears in a program being compiled
with Maclisp compatibility, the autoloading of loop.o will result in
the definition of DEFCONST in loop.o overriding the one in machacks.o.
In any case, both don't work properly in terms of pervading the "declare
special" through compiles and loads. The "defvar" in macros.l does work
properly, and "defconst" in machacks.l should be modified to work like
"defvar", which uses some strange feature named "liszt-declare".
I suggest that "loop.l" should not redefine any standard functions
(names such as "loop-internal-defconst" would be more appropriate for
the internal functions) and "defconst" in "machacks.l" needs to be fixed.
REPEAT BY:
1. Compile something in Maclisp mode which begins by making
macros pervasive with (declare (macros t)), and uses DEFCONST.
2. Load the above into another compilation and reference the
variable mentioned in the DEFCONST, and see if the compiler
issues a "declared special by compiler" warning message.
It does for me.
_______________________________________________________________________________
lisp/Makefile--ucb root%oregon-grad.csnet@csnet-relay.arpa 21 Aug 84 +FIX
In the 4.2 BSD distribution, files in /usr/lib/lisp are
minor version number .69, whereas the lisp and liszt binaries,
and the source for the Franz Lisp system, is .79.
Also, a "make slow" of the Franz Lisp system does not
adequately clean out the old *.o files in /usr/lib/lisp.
REPEAT BY:
Inspection: "strings -a /usr/lib/lisp/version.o" shows it to be
minor version number .69, whereas "lisp" and "liszt" reports
.79. This can result in a newly-built lisp and liszt reporting
.69, if the following is done:
% cd /usr/src/ucb/lisp
% make fast
(No "make copylibrary" was done since it was believed that
/usr/lib/lisp was already the same as the source, since both
were as distributed with 4.2 BSD.)
This results in lisp and liszt being minor version .69,
made from the .69 versions of /usr/lib/lisp/*.l .
Later, when this is done:
% make copylibrary
% make slow
the minor version remains .69, since the copylibrary is done
with "tar", which preserves the original dates of the *.l
source files, the /usr/lib/lisp/*.o files from the previous
"make fast" have later dates than these *.l files, and hence
the *.o files are not rebuilt from the version .79 *.l files, so
the *.o files remain version .69. These *.o files are then
used to build lisp and liszt.
FIX:
Obviously, the distributed /usr/lip/lisp should be made
consistent with the source.
However, the following change to the Makefile should be made
to ensure that the /usr/lib/lisp/*.o files get rebuilt during
a "make slow":
137c137
< (X=`pwd`; cd ${LibDir} ; make Liszt=$$X/${LisztD}/nliszt all)
---
> (X=`pwd`; cd ${LibDir} ; make Liszt=$$X/${LisztD}/nliszt clean all)
RCS log message:
----------------------------
Added "clean" to /usr/lib/lisp portion of "make slow", to avoid
this situation:
1. Installer does "make fast", leaving new .o and .x files in
/usr/lib/lisp.
2. Installer later does "make copylibrary". Since this is done
with "tar", original dates of .l files are preserved.
3. A subsequent "make slow" (before the "clean" was added) will
believe that /usr/lib/lisp is up-to-date, since new .l files
are older than .o and .x files left from previous "make fast".
----------------------------
Bruce Jerrick
Oregon Graduate Center
(503) 645-1121 ex. 355
CSNet: bruce@Oregon-Grad
UUCP: ...tektronix!ogcvax!bruce
_______________________________________________________________________________
lisp/Makefile--ucb lepreau@utah-cs (Jay Lepreau) 14 Nov 83 +FIX
The top-level Makefile fails to pass on flags via the
${MFLAGS} macro, contrary to convention. This is the real
problem; however, this in combination with a both in
lisp/franz/Makefile cause "make -k clean" to fail:
that one needs a -f flag to rm on its clean entry.
REPEAT BY:
cd /usr/src/ucb/lisp; make clean (or make -k clean)
FIX:
Add ${MFLAGS} on every invocation of make on a subdir.
Add the -f flag.
_______________________________________________________________________________
lisp/franz--ucb jbn@FORD-WDL1.ARPA 6 Mar 84
Franz reader improperly converts atom names beginning with digits
when (sstatus uctolc t) is enabled, as in Maclisp mode.
A name of the form "1FOO" reads in as "1foo" but
"1DOO" reads in as "1Doo", because the reader tries to scan
the name as a number and accepts the D (or E) as a possible
exponent indicator. When "getnum" finds a non-numeric after
the "D", it backs out, but does not perform upper case to lower
case conversion when it does so. Thus, the D or E remains in
upper case but the remaining characters get converted to lower
case.
The "D" and "E" characters are hard-coded in "getnum"; it isn't
even possible to fix this by changing the readtable. This makes
the bug serious, since there is no simple work-around.
All Maclisp mode users with names of the form [0-9][DE].* will
have this problem.
REPEAT BY:
(sstatus uctolc t) ; turn on upper case conversion
(print '1ABCDEF) ; prints |1abcdef| -- OK
(terpri)
(print '1DEFABC) ; prints |1Defabc| -- WRONG
(terpri)
_______________________________________________________________________________
lisp/franz/lam7.c--ucb pur-ee!malcolm (Malcolm Slaney) 18 Jan 84 +FIX
The (*process) routine in Opus 38.69 of Franz Lisp does not properly
close the pipe file descripters that the child has open. This problem
only shows up when the user's shell is the Bourne shell. It looks
like csh closes any excess file descripters before exec'ing a
sub-process while the Bourne shell doesn't.
The result for Bourne shell users is that there is no way to pass
an EOF to the sub-process because the sub-process has both ends
of the pipe open.
REPEAT BY:
For users of the Bourne shell.....
SHELL=/bin/sh
export SHELL
lisp
(setq port (*process-send '/bin/cat))
(patom 'hello port)
(close port)
(*process 'ps)
..... You will see that the cat is still running, even
though the lisp end of the pipe is closed.
_______________________________________________________________________________
lisp/franz/vax--ucb salkind@nyu (Lou Salkind) 9 Dec 83 +FIX
rawhlisp can not be built from the distributed sources (several
important franz applications need this).
REPEAT BY:
In the vax directory, type make rawhlisp. You will get _brk
undefined.
_______________________________________________________________________________
lock.c--ucb hpda!hpdsd!edmund (Ed Trujillo) 7 Mar 84 +FIX
When an ctrl-d (EOT) is typed to the lock program, the
fgets call returns NULL. Wherebye the program gets
into an infinite loop dumping ascii 7's (bells) to stdout.
REPEAT BY:
% lock
Key: <type in a key>
Again: <repeat it>
Now hit ctrl-d and the fun begins.
FIX:
The terminal becomes brain damaged due to the handling of
EOT in cooked mode. The fix is simply to put the terminal
in CBREAK mode. See enclosed diff.
31a32
> ntty.sg_flags |= CBREAK;
_______________________________________________________________________________
login.c--bin mark@cbosgd.UUCP 6 Jan 83 +FIX
In /usr/src/cmd/login.c, check the 2nd instance of TIOCLSET.
(The first is an ifdef, the second is an ioctl.) In my copy (which
I think has not changed in that part from 4.1BSD) the 3rd parm passed
to the ioctl is 0. It should be a pointer to a location containing 0.
The symptom of this was than when I made another change to login,
suddenly several bits (nohang, etxack, and intrup) were getting set
when people logged in, and nohang caused the system not to send SIGHUP
when they logged out.
We are still having a similar problem on our dialup - the process
doesn't get a SIGHUP (nor does the DZ notice that carrier is gone)
until the next person dials up. Our dialup is a VENTEL 212+ and I
suspect that the dialer is interactively raising carrier thinking
someone wants to dial out or some such thing.
Mark
_______________________________________________________________________________
lpr--usr.lib hipl!msl@nyu (Mike Landy) 12 Apr 84
The -l switch to lpr doesn't seem to work. If you use it, the spooler entry
does have a "card" beginning with the letter 'l', as it should, but thereafter,
lpf is run without the '-c' switch, which is what I thought should be the
desired effect, leading to control characters being passed. I don't know
whether this is an lpd problem or perhaps a /etc/printcap problem?
Sincerely,
Michael Landy
New York University
Department of Psychology
.....cmcl2!hipl!msl
(212) 598-2249
_______________________________________________________________________________
lpr--usr.lib sun!shannon (Bill Shannon) 19 Dec 83
If you are on a host named "host-a" on network A, which is also
attached to network B and known as "host-b" on network B, and
the system the printer is on is attached to network B, lpr will
spool files to the printer and say they came from "host-a". If
you then try to do lprm, the remote printer system will look up
your Internet address and determine that your are on "host-b"
and therefore won't let you remove the job because "host-a" !=
"host-b", even though they are the same physical host.
REPEAT BY:
See above.
_______________________________________________________________________________
lpr/printjob.c--usr.lib jeff@fluke (Jeff Stearns) 22 Oct 84 +FIX
If a job is queued to a printer with a request that it be indented,
subsequent printouts within the same queue run will be given the
same indentation.
The problem exists because the instantiation of /usr/lib/lpd which
processes the queue doesn't reset all its variables after printing
each job. Specifically, it doesn't reset the indent amount to zero.
REPEAT BY:
Queue two files to a printer, asking that only the first be indented:
% lpr -i8 /tmp/foo; lpr /tmp/foo
Note that BOTH printouts will be indented.
_______________________________________________________________________________
lpr/printjob.c--usr.lib root%oregon-grad.csnet 1 Sep 84 +FIX
Although printcap supports "xc" and "xs" entries to clear
or set local mode bits of a tty, this has no effect because
the tty's line discipline is not set to the "new" discipline.
REPEAT BY:
Include an "xc" or "xs" entry in the /etc/printcap file for a
printer connected via a tty line, then while a job is
printing, do a "pstat -t" to observe that the DISC field is
*not* "ntty", in which case the local mode settings are
ignored (see tty(4)).
Warning: Don't use an "stty > ..." command to check the
settings; it will block while lpd is using the printer.
FIX:
Add lines (marked with '+' below) to printjob.c to set
line discipline if XC or XS is set:
/*
* setup tty lines.
*/
static
setty()
{
struct sgttyb ttybuf;
register struct bauds *bp;
+ int ldisc = NTTYDISC;
.
.
.
if (XC) {
+ if (ioctl(pfd, TIOCSETD, &ldisc) < 0) {
+ log("cannot set tty new line discipline");
+ exit(1);
+ }
.
.
.
if (XS) {
+ if (ioctl(pfd, TIOCSETD, &ldisc) < 0) {
+ log("cannot set tty new line discipline");
+ exit(1);
+ }
.
.
.
=========================================
Bruce Jerrick
Oregon Graduate Center
(503) 645-1121 ex. 355
CSNet: bruce@Oregon-Grad
UUCP: ...tektronix!ogcvax!bruce
_______________________________________________________________________________
GENERAL INFORMATION ON THE 4.2 BUGLIST FROM MT XINU
_________________________________________________________________
--IMPORTANT DISCLAIMERS--
Material in this announcement and the accompanying reports
has been edited and organized by MT XINU as a service to the
UNIX community on a non-profit, non-commercial basis. MT
XINU MAKES NO WARRANTY, EXPRESSED OR IMPLIED, ABOUT THE
ACCURACY, COMPLETENESS, OR FITNESS FOR USE FOR ANY PURPOSE
OF ANY MATERIAL INCLUDED IN THESE REPORTS.
MT XINU welcomes comments in writing about the contents of
these reports via uucp or US mail. MT XINU cannot, however,
accept telephone calls or enter into telephone conversations
about this material.
_________________________________________________________________
Legal difficulties which have delayed the distribution of
4.2bsd buglist summaries by MT XINU have been resolved and
three versions of the buglist are now available.
The current buglist has been derived from reports submitted
to 4bsd-bugs@BERKELEY (not from reports submitted only to
net.bugs.4bsd, for example). Reports are integrated into
the buglist as they are received, so that any distributions
are current to within a week or so.
Buglists now being distributed are essentially "raw". No
judgment has been passed as to whether the submitted bug is
real or not or whether it has been fixed. Only minimal edit-
ing has been done to produce a manageable list. Reports
which are complaints (rather than bug reports) have been
eliminated; obscenities and content-free flames have been
eliminated; and duplicates have been combined. The result-
ing collection contains over 500 bugs.
Three versions of the buglist are now ready for distribu-
tion:
2-Liners:
Two lines per bug, including a concise description, the
affected module, the submittor. Approximately 55K
bytes, it is being distributed to net.sources con-
currently with this announcement.
All-but-Source:
All material, except that all but the most inocuous of
source material has been removed to meet AT&T license
restrictions. Nearly a mega-byte, this will be
distributed to net.sources in several 50K byte pieces
later this week.
A paper listing or mag tape is also available, see
below.
Please note that local usenet size restrictions may
prevent large files from being received and/or
retransmitted. MT XINU will not dump this material on
the net a second time; if your site has not received
material of interest to you within a reasonable time,
please send for a paper or tape copy.
All-with-Source (FOR SOURCE LICENSEES ONLY):
4.2 licensees who also have a suitable AT&T source
license can obtain a tape containing all the material,
including proposed source fixes where such were submit-
ted.
Once again, MT XINU has not evaluated, tested or passed
judgment on proposed fixes; all we have done is organ-
ize the collection and eliminate obvious irrelevancies
and duplications.
A free paper copy of the All-but-Source list can be obtained
by sending mail to:
MT XINU
739 Allston Way
Berkeley CA 94710
attn: buglist
or electronic mail to:
ucbvax!mtxinu!buglist
(Be sure to include your US mail address!)
For a tape, send a check for $110 or a purchase order for
$150 to cover MT XINU's costs to the address given above
(California orders add sales tax). For the All-with-Source
list, mail us a request for the details of license verifica-
tion at either of the above addresses.