Date: Mon, 01 Jun 1998 16:06:00 -0700 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: schilling@fokus.gmd.de (Joerg Schilling), dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199806012306.QAA01852@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 01 Jun 1998 22:41:30 -0000." <199806012241.PAA27865@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> I have no problems with these functions as I believe that it neccessary > > >> to have readable error messages and perror() don't makes good error > > >> messages. > > >Great. Replace a set of standard error reporting functions with older, = > > >nonstandard ones. 8) This really sinks most of the rest of your argument,= > > >unfortunately. > > > > You are right from the view of a *BSD user but from the view of a > > mainstream UNIX user the BSD functions are non standard too and in > > addition non portable. And yours are standard? Or any more portable than the BSD library functions? I take your point that if you're adopting something into your own family you want it to conform, I'm just suggesting that your perspective is a bit warped. > I have to agree. I greatly dislike the err(3)/warn(3) functions. Among > other things they lead to a boatload of lint/compiler directives of the > form "/* NOTREACHED*/". This is only an issue if your error checking tools can't be informed that a function doesn't return. If your tools contain implicit information about the behaviour of exit(), abort(), longjmp() etc. then they are not portable either. > > Around 1990 the number of pure BSD users did go dramatically down because > > many vendors switched over to SVr4. No commercial UNIX incorporated things > > from 4.4BSD (if I rememer correctly) in contrary to the former behaviour of > > these companies. > > BSDI. There are other vendors using 4.4-derived code as well, not to mention the number of embedded platforms using 4.4-derived code. > > I believe that > 80% of all UNIX users have no access to err(). > > So I cannot call 4.4BSD mainstream or half the UNIX tree. I can make up numbers just as easily. But even using your numbers, 20% is too large to be ignored. > One fix: The correct "fix" is, of course, to use a set of functions suited to your application environment and then shim them out on a per-platform basis. That's just portability-101 again. > The correct way to get this behaviour is to turn on compiler whining > about unprototyped functions, and then set the apropriate POSIX version > before including headers. That's better, yes. It makes it more difficult to build sophisticated application-level services out of composite target environment services handled on a per-target basis. > > No doubt, there is a need for UNIX utilities with better error printing > > and standardized bahaviour and many ideas from 4.4 BSD are not bad, but > > they are not available outside *BSD. > > The function err(3)/warn(3) are farcical. Actually, err/warn are far from farcial. They provide a useful set of functionality commonly required for trivial commandline applications. They are available anywhere outside of the BSD environment you care to build or duplicate them. > > I hope you see, that I am sad to see that the BSD folks writes good > > software that cannot be shared without using the *BSD operating system. > > From my point of view this is not the right idea of free software. Which parts of the application or the library services it uses are not free? How are we supposed to raise the quality of the environment if not by doing new things? Do you expect us to accept stagnation as the price for lowest-common-denominator compatibility? > > >> P.S. > > >> I believe that the real problem might be that your program comes > > >> with a BSD license while my software comes with GPL. > > > > > >This is never a problem; BSD code can always be incorporated into a GPL = > > >product without having any significant impact on the GPL. The reverse = > > >is, regrettably, not the case. > > Actually, that's not true; the GPL has just as hard a time with the > UCB additional "restriction" of claim-credit in the UCB/CMU copyright. > This is gratuitous as hell on the part of the GPL, but there you have > it... You are referring to clause 6 in GPL2? This is violated so regularly that I would expect it to be almost unenforceable. A literal interpretation makes it impossible (in fact a violation of the GPL) to ask people to send you bug reports. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806012306.QAA01852>