guy@sun.uucp (Guy Harris) (09/26/85)
PLEASE, people: argv[argc] does NOT point to a string. It is a null pointer.
Code which dereferences it is illegal. If you want to write a program which
reads standard input if 1) no arguments are given or 2) an argument of "-"
is given, PLEASE check whether any arguments were given before checking if
an argument of "-" was given! (One would think that it was obvious that one
should first check if something exists before checking if it has a
particular property, but there's a hell of a lot of code that seems not
to...)
*** cat.c.BAK Mon Sep 23 13:06:36 1985
--- cat.c Wed Sep 25 11:57:05 1985
***************
*** 85,91
for (argv = &argv[optind];
optind < argc && !ferror(stdout); optind++, argv++) {
filenm = *argv;
! if (filenm[0]=='-' && filenm[1]=='\0' || stdinflg) {
filenm = "standard input";
fi = stdin;
} else {
--- 85,91 -----
for (argv = &argv[optind];
optind < argc && !ferror(stdout); optind++, argv++) {
filenm = *argv;
! if (stdinflg || (filenm[0]=='-' && filenm[1]=='\0')) {
filenm = "standard input";
fi = stdin;
} else {
Guy Harrishansen@pegasus.UUCP (Tony L. Hansen) (10/04/85)
The zero deference bug still exists in my Vr2 code. Does anyone think that for Vr3 they'll turn on the loader option to disallow zero deferences? Tony Hansen ihnp4!pegasus!hansen *** /tmp/cat.c Thu Oct 3 12:42:57 1985 --- /tmp/cat.c.new Thu Oct 3 21:30:24 1985 *************** *** 79,85 } for (argv = &argv[optind]; optind < argc && !ferror(stdout); optind++, argv++) { ! if ((*argv)[0]=='-' && (*argv)[1]=='\0' || stdinflg) fi = stdin; else { if ((fi = fopen(*argv, "r")) == NULL) { --- 79,85 ----- } for (argv = &argv[optind]; optind < argc && !ferror(stdout); optind++, argv++) { ! if (stdinflg || ((*argv)[0]=='-' && (*argv)[1]=='\0')) fi = stdin; else { if ((fi = fopen(*argv, "r")) == NULL) {
henry@utzoo.UUCP (Henry Spencer) (10/06/85)
> The zero deference bug still exists in my Vr2 code. Does anyone think that > for Vr3 they'll turn on the loader option to disallow zero deferences? Probably not until they run into the same situation that forced Berkeley to do something about it: a machine which *cannot* support a readable location 0. (Let there be no illusions that Berkeley fixed *NULL problems out of nobility or purity of heart; they fixed them because they had no choice if they wanted their code to run on the first Suns.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
hammond@petrus.UUCP (Rich A. Hammond) (10/07/85)
> > The zero deference bug still exists in my Vr2 code. Does anyone think that > > for Vr3 they'll turn on the loader option to disallow zero deferences? > > Probably not until they run into the same situation that forced Berkeley > to do something about it: a machine which *cannot* support a readable > location 0. (Let there be no illusions that Berkeley fixed *NULL problems > out of nobility or purity of heart; they fixed them because they had no > choice if they wanted their code to run on the first Suns.) > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry The sad thing about all this is that I know of development groups in AT&T Information Systems that have done the fixes, because they had machines that didn't have readable location zero's. However, getting USG to buy back those modifications (and others for porting) never seemed to work out. After all, AT&T IS is a fully separated subsidiary. Rich Hammond
shannon@sun.uucp (Bill Shannon) (10/08/85)
> Probably not until they run into the same situation that forced Berkeley > to do something about it: a machine which *cannot* support a readable > location 0. (Let there be no illusions that Berkeley fixed *NULL problems > out of nobility or purity of heart; they fixed them because they had no > choice if they wanted their code to run on the first Suns.) > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Actually, Sun made the fixes and gave them back to Berkeley, to help all the other poor slobs who started with 4.xBSD as a porting base. Berkeley was very good about taking these fixes back. If/when we get a line into AT&T, we will give them the fixes too. I hope they will also be willing to take back such fixes. I strongly urge both Berkeley and AT&T to build their systems such that access to location zero causes a fault, and then fix all the bugs that turn up. Bill Shannon
henry@utzoo.UUCP (Henry Spencer) (10/08/85)
> ... (Let there be no illusions that Berkeley fixed *NULL problems > out of nobility or purity of heart; they fixed them because they had no > choice if they wanted their code to run on the first Suns.) Actually, John Gilmore has reminded me that Berkeley did not fix the *NULL problems at all; Sun did the fixes, which were fed back to Berkeley. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
fair@ucbarpa.berkeley.edu (Erik E. Fair) (10/10/85)
In article <2859@sun.uucp> shannon@sun.uucp (Bill Shannon) writes: > >Actually, Sun made the fixes and gave them back to Berkeley, to help >all the other poor slobs who started with 4.xBSD as a porting base. >Berkeley was very good about taking these fixes back. If/when we get >a line into AT&T, we will give them the fixes too. I hope they will >also be willing to take back such fixes. I strongly urge both Berkeley >and AT&T to build their systems such that access to location zero causes >a fault, and then fix all the bugs that turn up. Due to various historical (hysterical?) reasons, the Dual Systems 68000 Version 7 UNIX port had an offset of 0x800000, so that doing *(0) resulted in a quick death by SIGSEGV. Aside from the programs which we ported that were tripped up by this, I remember patiently trying to explain to various customers who were porting other programs from the VAX and PDP-11 that this was not a bug in our hardware, but actually the sins of the programmer who wrote the program in the first place, coming home to roost. I don't think that I managed to convince all of them... There were two papers given at the Dallas USENIX Conference (Jan 1985) on this general topic: Latent Source Bugs and UNIX System Portability Alan Filipski, Motorola Microsystems Can't Happen or /* NOTREACHED */ or Real Programs Dump Core Ian Darwin & Geoff Collyer, University of Toronto Both papers are replete with examples of How Not To Do Things, cogent observations about portability, and guidelines for good coding practices. I recommend them highly to anyone who programs in C at any time, regardless of whether they intend to make their programs portable or not. Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU
edward@ukecc.UUCP (Edward C. Bennett) (10/11/85)
In article <10606@ucbvax.ARPA>, fair@ucbarpa.berkeley.edu (Erik E. Fair) writes: > There were two papers given at the Dallas USENIX Conference (Jan 1985) > on this general topic: > > Latent Source Bugs and UNIX System Portability > Alan Filipski, Motorola Microsystems > > Can't Happen or /* NOTREACHED */ or Real Programs Dump Core > Ian Darwin & Geoff Collyer, University of Toronto > > Both papers are replete with examples of How Not To Do Things, cogent > observations about portability, and guidelines for good coding > practices. I recommend them highly to anyone who programs in C at any > time, regardless of whether they intend to make their programs portable > or not. > > Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU OK, I'll bite. How do we obtain copies of these papers? -- Edward C. Bennett UUCP: ihnp4!cbosgd!ukma!ukecc!edward /* A charter member of the Scooter bunch */ "Goodnight M.A."
fair@ucbarpa.BERKELEY.EDU (Erik E. &) (10/14/85)
In article <279@ukecc.UUCP> edward@ukecc.UUCP (Edward C. Bennett) writes: > > OK, I'll bite. How do we obtain copies of these papers? From the inside page of the `USENIX Winter Conference, Dallas 1985 Proceedings' for additional copies of these proceedings, write: USENIX Association P. O. Box 7 El Cerrito, CA 94530 USA Price $20.00 (US), plus $15.00 (US) for overseas airmail. Both of the papers that I mentioned are in the proceedings of the Dallas Conference. Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU
al@mot.UUCP (Al Filipski) (10/14/85)
> > > > There were two papers given at the Dallas USENIX Conference (Jan 1985) > > on this general topic: > > > > Latent Source Bugs and UNIX System Portability > > Alan Filipski, Motorola Microsystems > > > > Can't Happen or /* NOTREACHED */ or Real Programs Dump Core > > Ian Darwin & Geoff Collyer, University of Toronto > > > > Both papers are replete with examples of How Not To Do Things, cogent > > observations about portability, and guidelines for good coding > > practices. I recommend them highly to anyone who programs in C at any > > time, regardless of whether they intend to make their programs portable > > or not. > > > > Erik E. Fair ucbvax!fair fair@ucbarpa.BERKELEY.EDU > > OK, I'll bite. How do we obtain copies of these papers? > Well, I'll send a reprint of my paper to anybody who wants one. Just send me your name and (physical) mailing address. ------------------------------------------------------------------------ Alan Filipski, UNIX group, Motorola Microsystems, Tempe, AZ U.S.A {seismo|ihnp4}!ut-sally!oakhill!mot!al | ucbvax!arizona!asuvax!mot!al ------------------------------------------------------------------------