Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA22396; Tue, 19 Jan 93 13:06:26 -0800
Message-Id: <9301192106.AA22396@postgres.Berkeley.EDU>
From: vis!greg@UCSD.EDU
Subject: Re: ANSIfication
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Greg Kemnitz's message of "Mon, 18 Jan 93 16:48:17 PST."
             <9301190048.AA17906@postgres.Berkeley.EDU> 
Date: Tue, 19 Jan 93 12:37:15 -0800

Please bear with the recapitulation of this thread; there seem to have
been some misunderstandings based on earlier messages.  I've used
ellipses (...) to condense earlier remarks.  To further reduce
confusion I've separated the ANSI discussion from the issues of Posix,
Make, GCC and whether Postgres is/should become freeware.

Robert Withrow:
	I desire to correspond with people who are involved in ...
	Ansification of the source.

Alan Glass:
	[ANSIfication] is on the agenda for the coming release.  We are
	trying to do this in a way that will allow compilation by non-ANSI
	compilers, and let us use the new ANSI features to best advantage.

Me:	Why ... allow compilation by non-ANSI compilers?  Doesn't this
	... reduce the benefit that ANSI C can provide?  What platforms
	do you consider important that do not yet support an ANSI compiler?

Greg Kemnitz:
	Postgres predates validated ANSI compilers on many platforms .... If
	we had everything to do over, starting in 1993, Postgres would almost
	certainly be implemented using C++ or at least ANSI C, but a quarter
	of a million lines of code is a big incentive to avoid talk of
	wholesale language changes.

It is a misconception that ANSI C invalidates older C code.  The truth
is that ANSI C compilers accept older (often called Classic, or K&R) C
programs with few if any changes required.  This was a requirement of
the ANSI C standardization process.  Correct use of ANSI C *reduces*
portability problems *inherent* in Classic C code.

What ANSI C provides is a few new constructs, e.g. function
prototypes, and many tighter definitions of formerly gray areas, e.g.
whether * is needed to call a function by a pointer.  It allows, but
deprecates many unsafe practices, e.g. old-fashioned function
declarations.

ANSI C compilers will compile software as it is migrated from Classic
C to take best advantage of ANSI C features, regardless of how slow
and piecemeal that migration goes.  Also, tools exist, e.g. protoize,
that can automatically upgrade old software to take advantage of some
ANSI C features.

On the other hand, a Classic C compiler will not compile a mixture of
Classic and ANSI features.  With significant effort one can use macros
and conditional compilation code which allow the optional use of ANSI
C features.  This degrades program readability and reliability, hence
the overall quality of the code.  Why do this to Postgres?

_Greg


J. Greg Davidson	Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA
 
vis!greg@nosc.mil					ucsd----+--vis
vis!greg@ucsd.edu		 			nosc----|

	*****************************************************
	*   Member of the League for Programming Freedom.   *
	*   For more info, write to league@prep.ai.mit.edu  *
	*****************************************************