Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: Rationale for my posting draft V7 C description
Message-ID: <CK27V96@xds13.ferranti.com>
Date: 19 Nov 90 22:09:31 GMT
References: <2451.273eb16b@verifone.com> <2713@lupine.NCD.COM>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 40

In article <2713@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
[ in the middle of a bunch of flames ]
> This group is for discussing the use of (and the rules of) ANSI C.  If you
> sense some hostility, it is probably because the people who read and write
> this group mostly want to see people starting using (and conforming to)
> the One and Only approved standard for the language C.

That's nice, but out here in the real world I don't ever expect to
see a real ANSI C compiler for the 40 or so pre-SCO Xenix-286 boxes we're
having to use (mainly, because iNTEL refuses to support PL/M on UNIX and
we've got a large investment in PL/M code).

For the next few years at least it will remain necessary to support K&R
compilers, and to write code so it won't break them. This means a lot of
ifdef __STDC__, and it helps to have a reasonable description of the state
of the art. I was glad to see it... though I don't need it personally I'm
not the only C coder here...

> // Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

Sorry, we don't have replacement parts in stock.

If you want to *help* the situation, write a deprotoiser that fixes up all
the calls... that is, if you have:

	extern void foo(float bar);

	...
		foo(3.0);
		foo(2);

It converts this to:

	extern foo();

	...
		(void)foo((float)3.0);
		(void)foo((float)2);

Otherwise people are going to have to keep coding in two languages.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com