haugj@pigs.UUCP (John F. Haugh II) (05/28/88)
I earlier posted about some difficulty a client had had compiling a
collection of C code I had written for him. He had informed me that
he had difficulty compiling the code, as he said, `On a number of
different compilers'. It turns out the `number' was 1 and the
`different compilers' was the C compiler which is provided with
VM on a 9370. However, other ANSI-like compilers should have similiar
troubles.
The declarations for the functions causing the trouble were as
follows:
struct node *stmt_expr (),
*smpl_expr (),
*r_mknode (),
*st_exp1 (),
.
.
.
*ag_total ();
with the actual function definition being of the form
static struct node *st_exp1 ()
{
.
.
.
}
Many person wrote that this did not cause them trouble on their
particular compilers. However, a few people with ``ANSI'' compilers
did mention some grief. Doug Gwyn, I believe, wrote in a follow
up article, for those of you who missed it, that yes, you must
declare the function to have the same storage class as the actual
function definition itself has. Thinking back (WAY BACK) I do
recall this ``feature'' being discussed as a way to inform the
compiler that the function linkage may be different for static
functions vs. global functions [ namely that certain segmented
machines may be able to generate `NEAR CALL's vs `FAR CALL's. ]
So in short, all declarations of a function must match the actual
form as the function definition itself.
- John.
--
The Beach Bum Big "D" Home for Wayward Hackers
UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS
"You are in a twisty little maze of UUCP connections, all alike" -- fortuneblarson@skat.usc.edu (Bob Larson) (05/28/88)
In article <138@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes: [discussing ANSI c function declarations:] > Doug Gwyn, I believe, wrote in a follow >up article, for those of you who missed it, that yes, you must >declare the function to have the same storage class as the actual >function definition itself has. Primos (Prime) C is an exmaple of a pre-ansi compiler that does require this. ANSI was not inovating, they were just following the strictest existing practice. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
chris@mimsy.UUCP (Chris Torek) (05/29/88)
In article <138@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes: [static functions must be *declared* static as well as *defined* that way (so says the dpANS); and] >Thinking back (WAY BACK) I do recall this ``feature'' being discussed >as a way to inform the compiler that the function linkage may be >different for static functions vs. global functions [ namely that >certain segmented machines may be able to generate `NEAR CALL's vs `FAR >CALL's. ] Since there is nothing that prohibits taking the address of a static function, to make static functions `near' rather than `far' (on the 80[12]86) requires reading the entire source file before generating code (to ensure that no other function makes the address of the static function available outside the current file). Hence the restriction on declarations is not useful for this purpose. (The assumption was that if the declaration matched the definition, the compiler could emit the `near' code `on the fly'. Since this is false, if the compiler is to use near calls, it must do enough work that resolving the declaration against the definition would be trivial.[*] There may be *other* good reasons to require that the declaration match the definition, such as helping the human reader.) [*] There is another method: One could wrap all `near' entry points with `far' versions. Again, this does not require that the declaration match the definition. (The discussion was not very long ago---perhaps a year or two. I remember posting a very similar refutation of the `near call' argument.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris