rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: woods@most.weird.com (Greg A. Woods)
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: RC => POSIX
Date: Wed, 26 Mar 1997 11:38:37 -0500	[thread overview]
Message-ID: <m0w9vif-00076wC@most.weird.com> (raw)
In-Reply-To: Bengt Kleberg's message of "Wed, March 26, 1997 09:33:04 +0100" regarding "Re: RC => POSIX" id <199703260833.JAA02345@uabx04c397.uab.ericsson.se>

[ On Wed, March 26, 1997 at 09:33:04 (+0100), Bengt Kleberg wrote: ]
> Subject: Re: RC => POSIX
> I interpreted Mr Rakitzis previous message as a suggestion that ANSI
> function prototypes should go, since K&R C is more portable (available
> on more systems).

The problem is that while prototypes help catch parameter mismatches,
they must be used with strict new-style function definition syntax,
esp. with some less lax ANSI compilers (this is due to incompatabilities
invoving type promotion in expressions between ANSI C and K&R C).  As a
result the code gets very messy if you try to #ifdef both styles.

Indeed pure K&R C is still far more portable, and with careful use of
lint, still safer (in the sense that more function call problems can be
prevented) than most ANSI compilers are today.

Where I'm getting at here is that the most portable style of C coding is
probably to use ANSI definitions and prototypes exclusively, and rely on
some tool such as unproto or ansi2knr to automatically support older
compilers.  BTW, I've had far better luck with unproto, and it doesn't
require any makefile magic if it's installed properly on the target
system, though ansi2knr (from the GNU automake distribution) is easier
to use since you ship it with the package and automake does all the
"right" things to build portable makefiles for using it.

This of course necessitates still running lint occasionally with k&r
type promotion checking turned on and inserting all casts necessary for
k&r in function calls.  This is probably what would be best for rc since
most of the developers are likely to use ANSI C compilers and thus can
benefit immeadiately from prototype checking even if they don't have a
working lint implementation in their enironments.

Personally I detest ANSI function definition syntax (it is difficult to
read and very inelegant), and so I stick to straight k&r C in my own
code and rely on lint for more complex syntax checking.  Prototypes can
even work if you're using an ANSI compiler that can be told to always
follow k&r type promotion (eg. GCC).

							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

  reply	other threads:[~1997-03-26 19:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-26  8:33 Bengt Kleberg
1997-03-26 16:38 ` Greg A. Woods [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-03-29 20:23 Bengt Kleberg
1997-03-27  9:58 Malte Uhl
1997-03-26 11:54 Byron Rakitzis
1997-03-26 16:45 ` 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=m0w9vif-00076wC@most.weird.com \
    --to=woods@most.weird.com \
    --cc=rc@hawkwind.utcs.toronto.edu \
    --cc=woods@weird.com \


* 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).