Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!motcsd!dms!albaugh
From: albaugh@dms.UUCP (Mike Albaugh)
Newsgroups: comp.std.c
Subject: Re: Reality check
Message-ID: <1172@dms.UUCP>
Date: 22 Oct 90 16:16:10 GMT
References: <1990Oct19.222246.23253@athena.mit.edu>
Organization: Atari Games Inc., Milpitas, CA
Lines: 78

From article <1990Oct19.222246.23253@athena.mit.edu>, by scs@adam.mit.edu (Steve Summit):
> In article <1171@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) (That's me) writes:
>>	It is darn hard (not impossible) to "fool" this approach, and
>>not too hard to implement it (I hacked my prologue generation in GCC
>>for a machine with the first five params passed in regs).
> 
> Note that another optimization which the standard now allows,
> which I expect compiler writers to begin taking advantage of, is
> to use a calling sequence which pops arguments in the callee for
> non-varargs functions.

	Let's back off a bit here. I was _not_ arguing for that it was
a good idea to call a variadic function without a prototype in scope.
I was also not arguing that the hack I mentioned was the final, official,
"right answer". I _was_ arguing that on most machines currently extant,
the relatively simple expedient of forcing register-passed params onto the
stack in varargs routines is a useful part of "defensive programming"
on the part of the compiler writer. It is often also a "space win" versus
having the caller do it. I am aware of the arguments that add up to "this
will not always be possible in an otherwise conforming implementation". As
Doug Gwyn pointed out, there are some really bad "hand rolled" variadic
functions out there. The sort of folks who are going to get bent out of
shape on a "non mainstream" implementation have more problems than calling
printf() without a prototype.

	_If_ someone has a good reason for wanting "callee pops args"
or for using a machine in which that is the "natural" way of doing things,
they are presumably adult enough to deal with properly prototyping
their own functions, and including the proper headers. Someone without
even that much discipline will not get far with the rest of their code (e.g.
calling a routine that returns a pointer without declaring it at all) on
such an implementation.

	_If_ on the other hand, an implementation _can_ (sans "cc"
options to the contrary) "do the right thing" to old, crufty, incorrect
code relatively easily it should. If it gives a diagnostic, so much the
better. But to just say "the standard says I don't have to, so go suck
a rock" is IMHO, a poor example of "quality of implementation". The
standard is a "contract" between the implementor and the user, but I would
_like_ to think there are more programmers involved here than lawyers :-).

	I am reminded of what happened to a friend of mine, whose company
had a new building constructed. The contract specified "Builder shall supply
lighting fixtures conforming to specification [on another page] at 10'
intervals in all hallways..." with the appropriate drawings referenced
and marked. When they took delivery of the building, there were _boxed_
light fixtures sitting along the walls in each of the referenced places.
Seems the _correct_ language was "Builder shall supply _and install_..."
Do we _really_ want to follow in this fine American legal tradition of
"Ha, Ha, got you!" ?


	RECAP: (All these are my _OPINIONS_ about "quality implementations"

	1) It is not too much to ask to require a definition of a variadic
function to use stdarg.

	2) Where it would be a real hassle to the implementor, it is not
unreasonable to require a declaration to include a prototype as well, but
such a requirement should be prominently pointed out to prospective purchasers.

	3) If the "customer" wants the benefit of such potentially dangerous
optimizations as non-widened parameters and "callee pops", he/she should have
to _ask_ for them, by including a prototype or using a compiler "switch" or
the like. This is unlikely to be a useful approach when calling variadic
library routines, unless the user has a great deal of discipline. Thus it
becomes a case of "2" above.

	Oh, yeah, I reserve a special place in hell for implementors
whose _own_ headers (and libraries) choke their own compilers. You
know who you are :-(

					Mike

| Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)