Undeclared function arguments

[K.LAUX]

 In article <8058 at rpp386.Dallas.TX.US>, jfh at rpp386.Dallas.TX.US (The Beach Bum) writes:
 > In article <2686 at hound.UUCP> rkl1 at hound.UUCP (K.LAUX) writes:
 > >	The reason that 'm' was not declared was that the body of the
 > >function did not reference the variable at all *AND* it was the last
 > >parameter in the formal argument list.  Since arguments are pushed on
 > >the stack from *right* to *left*, there was no need to know its size.
 > 
 > This is not portable, relevant, or correct.
 > 
 > The formal argument `m' has a default type of `m', hence the type and
 > size are known, as a matter of fact.  Regardless of `m' being referenced,
 > the type will always default to `int'.
 > 
 > The order of arguments on the stack, or even the existance of a stack,
 > is not an issue which is addressed by the language specification.  There
 > exists hardware in which a function with two arguments will pass the
 > actual parameters are passed in registers or pre-allocated regions of
 > memory.
 > 
 > >	It would be a different case if:
 > >
 > >	YYBACK (i, m, n)
 > >	
 > >	and only i and n were referenced because now the compiler would
 > >*have* to know the size of m in order to correctly reference n on the stack.
 > 
 > This would be correct if the size of `m' were not set by default to be
 > sizeof (int).  If the call were
 > 
 > YYBACK (i, m, n)
 > int	i;
 > struct	foo	m;
 > int	n;
 > 
 > and the size of `m' weren't known, THEN it MIGHT be an issue.  However,
 > only structure pointers do not require the size of the underlying structure
 > to be known.  Since `m' in this case is not a pointer, this exception does
 > not apply and the above example is illegal.
 
 	You're absolutely right about non-declared variables defaulting to
 'int'.  It's also true that stacks are not part of the language specification.
 However, its not uncommon for compilers to use a stack and to push arguments
 from right to left (MSC, AT&T, DEC...)
 
 	I find that I often need to check the assembly language generated to
 see just what's going on (usually I'm reworking already written code) and, upon
 reflection of writing the above, I can see I was definitely influenced by
 my experiences (...why is it *I* always have to find those subtle compiler bugs
 the hard way...oh, well).
 
 --rkl