rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Malte Uhl <Uhl@rrz.uni-koeln.de>
To: rc@hawkwind.utcs.toronto.edu
Cc: uhl@rrz.uni-koeln.de
Subject: Re: RC => POSIX
Date: Thu, 27 Mar 1997 04:58:50 -0500	[thread overview]
Message-ID: <199703270958.KAA08660@noc.rrz.Uni-Koeln.DE> (raw)

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 

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 

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 

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.


             reply	other threads:[~1997-03-27 22:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-27  9:58 Malte Uhl [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-03-29 20:23 Bengt Kleberg
1997-03-26 11:54 Byron Rakitzis
1997-03-26 16:45 ` Greg A. Woods
1997-03-26  8:33 Bengt Kleberg
1997-03-26 16:38 ` Greg A. Woods
1997-03-25 22:30 Byron Rakitzis
1997-03-24  9:18 Bengt Kleberg
1997-03-24 20:22 ` Greg A. Woods
1997-03-08  0:13 Byron Rakitzis
1997-03-06 17:40 Tom Culliton
1997-03-06 17:15 Alan Watson
1997-03-06 17:54 ` Scott Schwartz
     [not found] <199703061512.KAA21040@explorer2.clark.net>
1997-03-06 16:57 ` Malte Uhl
1997-03-06 16:54 Tom Culliton
1997-03-06 15:22 Tom Culliton
1997-03-06 14:09 Bengt Kleberg
1997-03-06 13:46 Tom Culliton
1997-03-06 10:16 Bengt Kleberg
1997-03-07  1:45 ` Greg A. Woods

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199703270958.KAA08660@noc.rrz.Uni-Koeln.DE \
    --to=uhl@rrz.uni-koeln.de \
    --cc=rc@hawkwind.utcs.toronto.edu \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).