Conference bulova::decw_jan-89_to_nov-90

Prototypes are a feature of ANSI C.  That's the universal standard for C
language compilers.  Which of course means you can't USE it, since nobody
actually IMPLEMENTS it.  Isn't it WONDERFUL to have a standard, portable
language?

Seriously, though, there are a lot of compilers floating around which don't
support full ANSI C.  One of them is our own "pcc" (default cc command) on
VAX/ULTRIX.  vcc (VAX C) supports prototypes (although not full ANSI C), and
MIPS cc supports prototypes (although also not full ANSI C... for example,
the current compiler has a bug which prevents use of "void *").  All of this
makes it extremely difficult to support multiple C language platforms without
"least common denominatoring".  With enough conditional code, you can use
prototypes on platforms that support it, and "void *" on platforms that support
it, and drop it all on platforms which don't.  DECwindows, however, kept things
simple, and didn't use any useful ANSI C features anywhere.

As for your final comments... prototyping isn't a "false sense of security",
or a "hassle".  Prototypes are the single most important feature to turn C
into a programming language (instead of an assembler, which is what it basically
was before).  It allows a compiler to provide type checking across calls.  Not
really a very abstract or complicated function.  Without prototypes, C doesn't
care how many arguments, or of what type, you pass to a routine.  That makes
it really easy to make stupid errors.  Kinda like programming in Bliss, y'know?
The whole idea of using a compiler instead of an assembler is that it catches
more errors at compile time instead of waiting until you happen to stumble
against it at run time.

(If I sound a bit bitter... I was forced to severely decrease the quality of
the GObE widget by dropping prototypes to support VAX/ULTRIX, and I didn't 
much like it.  More recently, I chose the alternative of complicating the CMA
portable reference implementation by including the conditional code necessary
to make it work right on useful implementations of C, and act stupid and say
"duh" in the right places on braindamaged implementations of C... and I didn't
much like that, either).

	/dave

    The following is an exerpt from one of our prototype header files which
    conditionally gives us prototypes if the compiler supports them.
    
    Regards,        
    
    	 	== ken miller ==
    
#ifdef __STDC__
# define	P(s) s
#else
# define P(s) ()
#endif

/* xtrapdi.c */
int   XETrapSetup P((xXtrapReq *request , ClientPtr client ));
void  XETrapDoReset P((void));
int   XETrapDispatch P((ClientPtr client ));
    
    /* etc., etc. */

  Re .2 - Thanks for the example Ken.

  Re .1 - Thanks for the information Dave. Someone else commented that ANSI C
  would be a very unusual standard if everyone actually implemented it :-)
  Sorry about hitting a raw nerve - I should have put a "IMHO" in - I use
  C in "assembler" mode quite happily and forgot that this is probably a
  religious issue. Thanks again.

  Frank

.2: Almost.  There are some problem cases if you only add conditional prototypes
in the header files.  C has odd rules about parameter types.  The most conspic-
uous example is floats.  If you have a routine that takes a float by value, and
you declare the routine as

	foo (c)
	float c;
	{
	...
	}

and define a prototype in the header as

	foo P ((float c));

Then... it won't work on compilers which support prototypes.  Because the
routine's implementation expects that c is a double, whereas (because of the
prototype), the caller actually passed a float.  You have to either change the
prototype to specify "double c", or else add conditional code so that the
routine is implemented with a compatible prototype, as

	#ifdef __STDC__
	foo (float c)
	#else
	foo (c)
	float c;
	#endif

There are other cases of default argument widening which don't affect the
argument list on OUR platforms, but might on others (such as short => int).
You CAN do it... it's just not trivial, and it's a little messy.

.3: Sorry for the soapbox.  I agree that it's a religious issue... which is
exactly what gets me aggravated.  I'm annoyed that C has such a fervent
religious following, and that many of its proponents simply don't comprehend
what a miserable little low level language it really is.  I feel the same way
about Bliss, by the way :-)

	/dave

Dave,

>many of its proponents simply don't comprehend
>what a miserable little low level language it really is.  

Was this really necessary?

-steve-

RE: .5

> Do you hear a buzzing noise around here?

No, but I don't see any clothes on the Great Emperor C, either.

C has the same advantages as FORTRAN had in its day:  it's a practical language
to write things in, and it's everywhere.  However, from a language aesthetics
viewpoint, it's a disaster.  No language that accepts 090 as a valid octal
constant can claim good syntactic aesthetics.

--PSW

.5:

>>many of its proponents simply don't comprehend
>>what a miserable little low level language it really is.  
>
>Was this really necessary?

No, it wasn't "really necessary".  Nor is most of the chatter in this notes
conference (or in most others).  But it sure felt good.

	/dave

I think Dave deserves credit for saying in an extremely mild and gentle
fashion what many of us have frequently wanted to say much more forcefully!

(As a former president said recently: "I might have included some profanity".)


	paul