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
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
next 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* 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 \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).