[net.unix-wizards] 4.2 bsd questions

ttang.uci-750a%rand-relay@sri-unix.UUCP (12/16/83)

I am in the process of installing the 4.2bsd system.  After building our
testing system and bring it up, I frequently get the following message
at the console:
	mcr0: soft ecc adddr 90c syn 73(or another number)
It seems that there is a soft error occurred at the memory controller.
I would appreciate any of your help if you could provide
me any information about this error and would be really helpful if you
could send me a fix for that or give me a pointer to where i can get the
appropriate info.  Thanx in advance.

/ttang
Arpa:ttang.uci@Csnet-relay
Csnet:ttang@uci
Uucp:ucivax!ttang
P.S:I do not have enough time to dig into the kernel to find out about
this error yet.

goldfarb@ucf-cs.UUCP (Ben Goldfarb Esq.) (12/24/83)

The error message you are getting indicates that you have a 
single-bit (correctable) error at location 0x0000090c in low
memory.  One way to get rid of it is to replace the memory
chip that corresponds to the appripriate bit position and 
address.  If you have non-Dec memory and the chips are socketed
this is possible for you to do.  Otherwise you'll have to 
have the board replaced.  

Actually, this is a problem you can live with, and you will probably
have to do so if you have Dec memory.  Since it is correctable, it
shouldn't bother you except for the annoying messages every ten
minutes if it is in a frequently accessed location.  I have had
a similar problem with 0x00023760 for a couple of months now; DEC
won't replace the board because it is only a single-bit error and
nothing else is affected.
				Ben Goldfarb
				decvax!ucf-cs!goldfarb

brett@wjvax.UUCP (Brett Galloway) (10/17/86)

I have a fairly long list of questions about the 4.2bsd C development
environment distribution.  Some deal with lint; some deal with apparent
bugs; and some deal with programming/use style.  I am posting here because it
seemed the best group for the overall mix of questions -- if you disagree, type
'n' now.

First, I have some questions about the declarations of getpid() and getppid().
In the 4.2bsd manual, getpid(2) and getppid(2) are both declared long.  Yet
everywhere else a pid is used, it is declared int, and getpid(2) and
getppid(2) are declared int in lint (/usr/lib/lint/llib-lc).  Which is
correct?  Which is going to be correct in the future?

Next, about lseek(2).  In the 4.2bsd manual, lseek(2) and its second argument
(the offset) are declared int, yet lint declares them long (and for that
matter, fseek(3) declares the offset to be long).  Which should be used?

Next, about select(2).  Chris Torek noted a while back to use (fd_set *)
instead of (int *) for the fd mask args to select(2).  That's fine.  But
4.2bsd lint doesn't like that.  Is 4.3bsd lint fixed?

Next, about times and time stamps.  Gettimeofday(2) and settimeofday(2)
return a timeval structures in which the seconds field is defined long.
Likewise, time(3C) and ctime(3) use long.  However, ftime(3C) (within the
timeb structure) uses time_t for the same item (the no. of seconds since
the epoch).  Likewise, stat(2) uses time_t for the time stamps.  However, in
lint, all the ctime(3) routines and time(3C) routines use time_t.  Which
is correct, and in which places?

Next, about some obvious bugs in the lint library.  Neither sys_siglist
(see psignal(3)) nor environ(3) (see getenv(3), environ(7)) is defined in
the lint library, which causes lint to bark about items used and not
declared.  Also, the argument to setjmp(3) in the lint library is wrong.

Next, a possible bug in lint itself.  In my experience, if va_alist is used
as the first argument in a function (i.e. the entire argument list is
variable), and /*VARARGS0*/ is used to tell lint that, lint still barks about
mismatches in the first argument.

Finally, some questions about curses.  First, curses fails to define unctrl()
(actually, _unctrl) in its lint library (/usr/lib/lint/llib-lcurses).
Second, lint's resetty() and setty() macros reference putchar() without
casting _flsbuf to (void), causing lint to complain about _flsbuf
returning a value which is always ignored.

====

I would like to write lint-free code, as far as that is possible.  More
importantly, I would like to write correct, portable code.  I would like to
know the status of the bugs above, and of long vs.  time_t (for times) and
long vs. int (for pids) in 4.3bsd, and even SYSV.

Please E-mail any answers; I will summarize.  Thanks in advance.

-- 
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett