Date: Mon, 01 Jun 1998 08:30:00 -0700 From: Mike Smith <mike@smith.net.au> To: Joerg Schilling <schilling@fokus.gmd.de> Cc: dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199806011530.IAA17978@antipodes.cdrom.com> In-Reply-To: Your message of "Mon, 01 Jun 1998 14:01:35 %2B0200." <199806011201.OAA16937@sherwood.gmd.de>
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. > I believe the suing with AT&T has been won and there is no need to make > programs look like they are not from a UNIX system. Bear in mind that BSD is half of the Unix family tree. The BSD libc API is at least as valid as any other. The err() family of functions are mainstream from 4.4BSD, so they are shared with all the current BSD family. There are some legitimate candidates for this complaint, eg. the stringlist functions, yes. > Please: > > - Put all non standard library extensions into a separate > libbsd and make this library portable. > ( you may add this library to the default library list of the > compiler on *BSD so there will be no need to change makefiles) 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. There is not likely to be much support for political emasculation of the BSD API. > - Make sure that programs don't rely on nonstandard modifications > of historical UNIX include files if there is a reason to compile > and run these programs on a non *BSD system ( e.g. it is a non > BSD kernel specific program). > > - Write man pages that use the stanmdard UNIX -man macros and not > non-standard modifications. Again, these would be fine if the BSD environment was somehow "non-standard". > 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. > In any case, it seems to be a good idea to have a combination of a > command line interpreter which allows easy sending of arbitrary commands > and a portable SCSI transport library. No kidding. This would be a very useful tool, especially if it were basically a library which could be linked with either a simple line-reading frontend or an application program... -- \\ 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?199806011530.IAA17978>