scott@tdpvax.UUCP (06/09/89)
This is for all you standards nuts out there. When declaring FUNCTIONS which is better. extern int atoi(); extern char *foo(); or int atoi(); char *foo(); They seem to be equivalent and I have found no mention in K&R. In fact, in K&R most often they use the second one. But on the systems I'm using (UNIX and SCO ZENIX) most often the standard headers use the first but not always. So which is best and why and is there any difference. I myself lean toward the first so that you know the function is not in the file. The second question deals with strcpy(). Is it like memcpy in that if the arguments memory overlap the behavior is undefined or is it different. Is pre-ANSI and ANSI different on this. Scott King trsvax!tdpvax!scott@uxc.cso.uiuc.edu Sorry no disclaimer, my company could care less what my opinions are or what I do with them.
geoff@cs.warwick.ac.uk (Geoff Rimmer) (06/12/89)
In article <4400001@tdpvax> scott@tdpvax.UUCP writes: > extern int atoi(); or > int atoi(); I prefer the former, except I would write it: extern int atoi( const char * ); To extern or not to extern - it really doesn't matter with FUNCTION declarations. In the case of variables, "extern int foo;" and "int foo;" can be very different. But let's not get into tentative definitions! > I myself lean toward the first so that you know the function is not > in the file. Not necessarily. If ultra.c contains the function eggnog(), and violet.c calls eggnog(), it is usual to put the declaration of eggnog in a header file ultra.h, and then have ultra.c and violet.c #include ultra.h. So, even though ultra.c is seeing the "extern int eggnog();", the function eggnog() *is* in the same file. > The second question deals with strcpy(). Is it like memcpy in that if the > arguments memory overlap the behavior is undefined or is it different. Is > pre-ANSI and ANSI different on this. For ANSI C: "There are two groups of string functions defined in the header <string.h>. The first have names beginning with 'str'; the second have names beginning with 'mem'. Except for 'memmove', the behavior is undefined if copying takes place within overlapping opjects." - K&R2 B3 p249. Geoff /---------------------------------------------------------------\ | GEOFF RIMMER | | email : geoff@uk.ac.warwick.cs | | address : Computer Science Dept, Warwick University, | | Coventry, England. | | PHONE : +44 203 692320 | | FAX : +44 865 726753 | \---------------------------------------------------------------/ "No representation without taxation!" - Rik Mayall, The New Statesman.
apte@helios.cs.duke.edu (Jitendra Apte) (06/12/89)
In article <4400001@tdpvax> scott@tdpvax.UUCP writes: > >This is for all you standards nuts out there. When declaring FUNCTIONS which >is better. >extern int atoi(); >extern char *foo(); >or >int atoi(); >char *foo(); >They seem to be equivalent and I have found no mention in K&R. I am not a standards nut, but when baffled by the same question a few months ago, I picked up K&R1 and sure enough, on pp192-193 we find the following about declarations : "At most one sc-specifier may be given in a declaration. If the sc-specifier is missing from a declaration, it is taken to be `auto' inside a function, `extern' outside. Exception : functions are never automatic". PS. `sc-specifiers' are auto, static, extern, register and typedef. From the above, I concluded that the two forms of declaring functions are completely equivalent. Jitendra. (Internet) apte@cs.duke.edu; (UUCP) {decvax|ihnp4|allegra}!duke!apte "Let us save the kid from abortion, so that he can grow up to steal bread, rob banks and murder people. Then we can kill him in the electric chair".
shankar@hpclscu.HP.COM (Shankar Unni) (06/14/89)
> This is for all you standards nuts out there. When declaring FUNCTIONS > which is better. > extern int atoi(); > or > int atoi(); Both are quite legal. From a purely coding-standard point of view, I use the first form for a function that is not in this compilation unit. I use the second form when it is a forward declaration for a function in this compilation unit. Makes the source a *little* easier to read. ---- Shankar.