Date: Mon, 1 Jun 1998 22:41:30 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: schilling@fokus.gmd.de (Joerg Schilling) Cc: mike@smith.net.au, schilling@fokus.gmd.de, dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199806012241.PAA27865@usr05.primenet.com> In-Reply-To: <199806011744.TAA17106@sherwood.gmd.de> from "Joerg Schilling" at Jun 1, 98 07:44:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >Only if you promise not to give me trouble about errx - as a FreeBSD > >> >utility their coding standard says to use that, and when > >> >in Rome do as the Romans do. > >> > >> To make it portable, I'll need to replace them with my routines > >> comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 > >> long before BSD intruduced things like that. > >> > >> 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. 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*/". Not to mention the amount of damage they tend to perpetrate on single-entry/single-exit architecture (which drastically reduces bug counts according to all four studies published on it), and the damage they do to internationalization via data-only changes. > My functions are portable though. I think that code that relies on anything more than perror(3)/strerror(3) is asking for trouble, personally. Direct access to sys_errlist and sys_nerr, as well as assumptions about errno, are just plain wrong. > 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. Also note that SVR4 was 55% or better BSD4.3 code (one of the reasons the suit went away). > 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. One fix: #if defined(__BSD44__) #define ERR(x) err x #else #define ERR(x) myfunction x #endif ... ERR((1, "%s", file_name)); > >What you are suggesting you want here is a portable "libbsd". This = > >will need more than just "non-standard" library extensions, as the = > >alternative would be to put almost all of the BSD library in here. > >Rather, what needs to be done is for someone that wants to port BSD = > >programs to other platforms to take the BSD libc and extract all those = > >components which are a superset of the desired target platform(s) APIs = > >and build a libbsd suited to each of the deficient targets. This wouldn't fly, for the reasons listed. 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. > 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. The real need is for a machine parsable name/value syslog(3) formatting and conventions. Much less than the J. Abela "Universal Format for Logger Messages" draft standard, which attempts to define a new protocol as well as a convention that is less than useful for agregating the status of services, seperate from the status of filters (services hang out; filters exit). With this information, it would be possible to write a syslogd that parses messages, and can, at any point in time, provide you with the status of services exported by your machine. The defenition of dependent relationships between services is left as an exercise for the people who don't want a SysV style rc.d mechanism (ie: how do I know DNS is up before I actually offer mail services, since mail services depend on a functioning DNS). Try this experiment: add a duplicate host name record for an upper and lower case version of a host name to your DNS. Send mail to "root@mydomain". Wait one hour. Delete the 39,000 bounce messages that were generated. > As one exaple, I now have my own termcap library that implements the > exellent idea of the TERMPATH environment. The 4.4BSD version could > not be used because it relies on the nonstandard BSD database system. > OK, I already started my termcap library in 1986 so there was no need for > the full effort of the complete implementation. BTW: I am using enhanced > versions of tgoto() and tputs() because these functions are portable. I think you are confusing termcap (BSD) with terminfo (Bill Joy at Sun). The termcap file is standard to all UNIX implementations, and has been for a long time, until UNIX vendors switch to terminfor to make it so users couldn't screw up terminal definitions (so they come screwed up from the factory, instead). There are valid reasons to have your own termcap library, but there aren't really valid reasons to have your own getcap()/tgetent() functions. You should use the platform native database mechanism (for example, you can get this information from VMS's database, even though most DEC products, like EDT and LSE, hard-code things and are too stupid to use the database themselves). > 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. The big problem here is that you have a gratuitously different "make" program; probably GNU make, which needs ridiculously complex makefiles to describe common operations. I have never understood why putting commonly performed operations into each and every Makefile was a good design decision.... > >> 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... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199806012241.PAA27865>