Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!paperboy!osf.org!dbrooks
From: dbrooks@osf.org (David Brooks)
Newsgroups: comp.lang.c
Subject: Re: Func Protos with K&R Func Defs
Message-ID: <19546@paperboy.OSF.ORG>
Date: 4 Mar 91 16:17:50 GMT
References: <11614@jpl-devvax.JPL.NASA.GOV> <1991Feb28.021715.18153@athena.mit.edu>
Sender: news@OSF.ORG
Reply-To: dbrooks@osf.org (David Brooks)
Organization: Open Software Foundation
Lines: 31

jik@athena.mit.edu (Jonathan I. Kamens) writes:
|>   Now, you may get lucky for a while any only run into compilers that leave
|> the same amount of space on the stack for chars and ints.  But eventually
|> you're going to run into a compiler that doesn't.  And you're going to lose.

For all the lambasting Jonathan has gotten, he speaks truth here
(although I would put "un" before "lucky").

I recently saw the dangerous situation referred to in previous posts:
some routines with narrow arguments, and an attempt to cover both
prototyping and non-prototyping compilers with #ifdefs.

So, player A compiles the library with prototypes. She hands the
binary to player B, who compiles an application without using
prototypes (because he's got an old compiler).  Potential chaos
results: the application widens its arguments and the library expects
them unwidened.

Unfortunately, the whole mess was tested with gcc as the prototyping
compiler, and our gcc was built so that it leaves the same amount of
space on the stack for ints and chars (I understand this is a gcc
configuration option).  So the chaos remained potential, and
unnoticed, until it met up with a customer whose compiler happened to
like saving space on the stack.

This was not nice from a customer service standpoint.  There's a moral
here somewhere; maybe it's "read the FAQ".
-- 
David Brooks				dbrooks@osf.org
Systems Engineering, OSF		uunet!osf.org!dbrooks
"It's not easy, but it is simple."