[comp.lang.c] moving towards the standard ANSI with old c code

jjk@jupiter.astro.umd.edu (Jim Klavetter) (04/20/91)

2 related sets of questions:

1.  What is the timescale for all compilers to be ANSI?  And what is
the timescale for most compilers not accepting old c (I know it is
often called K&R c, but I will use the term old C to mean nonANSI c)?

2.  When should I be worrying about updating my libraries (if not my
programs) to ANSI c?  Should this be done all at once or can I do it
as needed?

It is obvious that it needs to be done sometime, but when?

jjk@astro.umd.edu also for Athabasca and Reudi
Jim Klavetter
Astronomy
UMD
College Park, MD  20742

burley@albert.gnu.ai.mit.edu (Craig Burley) (04/20/91)

In article <8452@umd5.umd.edu> jjk@jupiter.astro.umd.edu (Jim Klavetter) writes:

   2 related sets of questions:

   1.  What is the timescale for all compilers to be ANSI?  And what is
   the timescale for most compilers not accepting old c (I know it is
   often called K&R c, but I will use the term old C to mean nonANSI c)?

ISO has mandated that all C compilers be ANSI compatible by November 5, 1991
at 5:00 pm GMT, and that all C compilers no longer accept old C code not
conforming to ANSI C requirements by June 12, 1992 at 3:45 pm GMT.  The
first requirement can be gotten around by not calling a compiler a C
compiler, but calling it something else instead.  The second can be gotten
around by providing a compiler switch to allow K&R C, although ISO mandates
that this switch not be made the default on any installation except PDP-11
systems not connected to networks more than 10% of their mean annual uptime.

   2.  When should I be worrying about updating my libraries (if not my
   programs) to ANSI c?  Should this be done all at once or can I do it
   as needed?

If you are a compiler vendor, you should do the update all at once and by the
1991 date mentioned above.  If you are a user, the answer depends on when
and whether you will be compiling and/or linking your application with an
ANSI C compiler/library and where you live or work.

   It is obvious that it needs to be done sometime, but when?

While ISO doesn't mandate application conversion timeframes, the U.S.
Government Center for Computer Applications Maintenance (gccam) does;
however, the dates vary according to geography (usually the city nearest to
where you live or, more typically, where your corporation has its main
business address).

For information on these dates, call gccam at 1-800-256-5377.  If a recording
comes on and states a number, ignore anything else it says, and that number is
the number of days you have left to convert all your code over to ANSI C, as
this means the countdown has begun for your area.

(This applies only to existing C code; existing Fortran code need not be
converted over to Fortran 90 code for quite some time, pending finalization
of the standard by X3J3.)

   jjk@astro.umd.edu also for Athabasca and Reudi
   Jim Klavetter
   Astronomy
   UMD
   College Park, MD  20742

You wouldn't be a freshman, would you?  (-:
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu

barmar@think.com (Barry Margolin) (04/20/91)

In article <8452@umd5.umd.edu> jjk@astro.umd.edu (Jim Klavetter) writes:
>1.  What is the timescale for all compilers to be ANSI?  And what is
>the timescale for most compilers not accepting old c (I know it is
>often called K&R c, but I will use the term old C to mean nonANSI c)?

Conformance with standards is purely voluntary in the US, driven by market
forces.  Government contracts generally require products that conform to
national standards, so vendors who want to do business with the government
will probably have conforming compilers as soon as possible.  If compiler
purchasers stop giving business to vendors who supply nonstandard
compilers, they will become extinct pretty soon.  The biggest problem is
system vendors who include a C compiler with the OS -- purchasers of such
systems generally don't base their decision just on the C compiler that is
included, so they will often take a system with an old C compiler because
they want the features of the rest of the system.

>2.  When should I be worrying about updating my libraries (if not my
>programs) to ANSI c?  Should this be done all at once or can I do it
>as needed?

Your best bet is to start as soon as possible, but update it into code that
will work in both ANSI and pre-ANSI C.  You can use macros to minimize the
number of places where you must distinguish between the two dialects.  For
instance, you can put the following in a header file that all your code
includes:

#if _STDC_ == 1
#define ARGS(x) x
#else
#define ARGS(x)
#endif

Then you can write the following:

int foo (ARGS((char*, int)));

In ANSI C this will become a function prototype, and in pre-ANSI C it will
become a function declaration.

You can also try to find places in your code that are dependent on language
features that are different in the two dialects, such as the automatic
promotion of various arithmetic types during function calls, and recode
them so that they work in both environments.

Using techniques such as these, there's very little code that can't be made
to run in both dialects.  ANSI C was designed to be mostly upward
compatible with most common pre-ANSI implementations of C.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

gwyn@smoke.brl.mil (Doug Gwyn) (04/21/91)

In article <8452@umd5.umd.edu> jjk@astro.umd.edu (Jim Klavetter) writes:
>1.  What is the timescale for all compilers to be ANSI?

WHat makes you think there IS a time scale for that?
My guess is that old-style C environments will continue to be
encountered by many of us for the next five years, and that
within the next two years almost all new computer acquisitions
could reasonably start to specify C standard conformance.

>And what is the timescale for most compilers not accepting old c (I
>know it is often called K&R c, but I will use the term old C to mean
>nonANSI c)?

Since standard C is for the most part a superset of "K&R C",
old, carefully written C code should continue to be usable into
the foreseeable future.

>2.  When should I be worrying about updating my libraries (if not my
>programs) to ANSI c?  Should this be done all at once or can I do it
>as needed?

What libraries are you talking about?  I don't understand why you
think there is a problem to be solved here.