From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from noc.rrz.Uni-Koeln.DE ([134.95.100.209]) by hawkwind.utcs.utoronto.ca with SMTP id <24637>; Thu, 27 Mar 1997 17:06:05 -0500 Received: from noc (localhost [127.0.0.1]) by noc.rrz.Uni-Koeln.DE (8.8.5/8.8.4) with ESMTP id KAA08660; Thu, 27 Mar 1997 10:58:51 +0100 (MET) Message-Id: <199703270958.KAA08660@noc.rrz.Uni-Koeln.DE> X-Mailer: exmh version 2.0gamma 1/27/96 To: rc@hawkwind.utcs.toronto.edu cc: uhl@rrz.uni-koeln.de Subject: Re: RC => POSIX Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Mar 1997 04:58:50 -0500 From: Malte Uhl Fellow rc'ers, I'd like to vote in favour of modifying rc's code for Posix compatibility. Not because Posix (and XOPEN for that matter) compatibility is a good thing in itself, but because Posix provides a standard way to avoid BSD'isms and SysV'isms. Even Windows NT claims to be Posix conformant. Conforming to Posix and XOPEN standards does reduce porting efforts! This is from personal experience. But how many systems are there not supporting these standards? Well, few compared to the number of up to date or recently upgraded systems (let's say no older than 3 years). Even the GNU C library, Linus, NetBSD and Minix claim to be compatible. On those systems not compatible one can choose to run the 1.5 version, or alternatively install their own Posix compatibility library. Now, let me comment on the claims that K&R C + lint is more portable that ANSI C: First of all, one has to redo the lint checking on every (new) system. If lint does find problems, one will have to redo the neccessary changes, too, leaving asize the fact that some people will not be able to do this because of a lack of knowledge. Alternatively, lint checking can be done once for every supported system, but then there'll be quite a few #ifdef's. Given lint does not find (m)any problems, I postulate it could have been coded in ANSI C as well. Secondly, even if all my above ranting were false, I wonder why Ansi C + lint should be inferior. Also note, that ANSI C standardizes some part of the C library. Thirdly, the problem with K&R vs. ANSI declarations has long been solved by the GNU ansidecl.h header. Well, ok, not solved but alleviated. About GNU autoconf, let me say that I it's a bitter-sweet thing. For those who do not know, it's a feature test facility, generating C header files for a particular system from an abstract specification made by the developer of the software. It's sweet because it does it's job very well. But it's bitter because it doesn't check for groups of features, but each one on its own, e.g. it does not test if a system is ANSI C/Posix compatible and then configures the software to use all the Posix features, but tests every feature required independantly of the others. If, as a programmer, you should choose to use poll and select, autoconf will check both features and allow you to use both if available, although there's no point in doing so. In my opinion autoconf should configure the software to use either a native API or a standard API but not allow features to be mixed up. There should at least be a warning in this case. And now for those who are still reading, I know that Posix is not a single fixed standard, covering all fields of system programming. But it does offer some very useful features, such as signal semantics which is a well thought out generalization of BSD and SysV style and it offers standard access to several timer functions and job control, too. To me, this is reason enough to stick to Posix/XOPEN wherever possible. Malte