al@gtx.UUCP (01/16/88)
To illustrate a point about C, I had occasion to write the following
toy program:
#include <stdio.h>
main()
{
int (*x)();
x = printf;
(*x)("Hello, world\n");
}
and was slightly irritated when cc (one on SV, one on BSD4.2) choked,
saying "line 5: printf undefined". Neither the stdio.h on my AT&T 7300,
nor the one on the SUN has
int printf();
in it. This is one reason (maybe not an earth-shaking one, though) why
the standard header files SHOULD contain declarations even for int
procedures. I expect more will when ANSI C compilers come along
because of the additional information in the prototypes. (Are
declarations for library functions required by the standard? where
will the system call declarations go?)
mount /dev/soapbox .
In my opinion, one of the main design flaws in C is the rule that
makes procedures int by default. We had some vax code that called
malloc() but didn't include malloc.h. Works fine on the vax, but on
the M68000, malloc puts its return value (an address) in a0, then the
calling program picks up the "int" it expects from d0, and the fun
begins. Lint really pays for itself on occasions like this.
umount /dev/soapbox
----------------------------------------------------------------------
| Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
| {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
----------------------------------------------------------------------
I wanted to put the quotation from Shakespeare about the "sea change"
here, substituting "C" for "sea", but couldn't remember how it goes.
Since looking something up would violate some Usenet rule, just pretend
it's here.gwyn@brl-smoke.UUCP (01/16/88)
In article <528@gtx.com> al@gtx.UUCP (Al Filipski) writes: >(Are declarations for library functions required by the standard? where >will the system call declarations go?) Yes, each header defines/declares the associated macros/functions. "A place for everything and everything in its place." Note, however, that in most cases a macro is permitted, so if you really want the function (for example, to obtain a pointer to it) you have to not only #undef the name but also explicitly declare the function yourself (in accordance with the standard's interface specification for the function). So your example would really not be any easier under ANSI C. >In my opinion, one of the main design flaws in C is the rule that >makes procedures int by default. From today's point of view, yes, but before the advent of "void" it was quite convenient. Of course it can't be changed now, due to the amount of correct existing code that would be invalidated. By the way, failure to properly declare malloc() is a common bug. It seems that since everyone has to cast its return result to the proper pointer type, they fail to observe that letting it default to int before the cast is simply wrong.
g-rh@cca.CCA.COM (Richard Harter) (01/17/88)
In article <7111@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >>In my opinion, one of the main design flaws in C is the rule that >>makes procedures int by default. > >From today's point of view, yes, but before the advent of "void" >it was quite convenient. Of course it can't be changed now, due >to the amount of correct existing code that would be invalidated. > >By the way, failure to properly declare malloc() is a common bug. >It seems that since everyone has to cast its return result to the >proper pointer type, they fail to observe that letting it default >to int before the cast is simply wrong. From yesterday's viewpoint also. We (SMDS) don't use void or hardly anything else that is not in K&R, for strictly pragmatic reasons of portability. However, even in the context of K&R, integers defaults were a design error. One could have just as well had the rule that all items had to have a type declaration. The 'integer default' rule is the sort of thing that leads to accidental bugs, and code that isn't portable. Incidentally, I am inclined to believe that the decision to have only functions (which, in principle return a value) and not also have procedures (subroutines) which do not return a value was a design error. The idea that procedures are a special case of functions is elegant and all that, but the introduction of 'void' is a tacit admission that this particular conceptual unification was not desirable. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
karl@haddock.ISC.COM (Karl Heuer) (01/18/88)
In article <7111@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Yes, each header defines/declares the associated macros/functions. "A place >for everything and everything in its place." Note, however, that in most >cases a macro is permitted, so if you really want the function (for example, >to obtain a pointer to it) you have to not only #undef the name but also >explicitly declare the function yourself (in accordance with the standard's >interface specification for the function). Whoa! I thought that, for precisely this reason, the header files were required to supply prototyped declarations even for those functions that are hidden by macro definitions. This is certainly implied by the last sentence of footnote 61 in section 4.1.5 of the Oct86 dpANS. Better check this again, Doug. If it's really not in the latest Draft, I'd like to know why not. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/18/88)
In article <2302@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >Whoa! I thought that, for precisely this reason, the header files were >required to supply prototyped declarations even for those functions that are >hidden by macro definitions. Oops, you're right, the footnote (!) does say that #undef of the macro will reveal the prototype. Thanks for the correction. (What a strange specification!)
daw@houxs.UUCP (David Wolverton) (01/18/88)
In article <7111@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > In article <528@gtx.com> al@gtx.UUCP (Al Filipski) writes: > >In my opinion, one of the main design flaws in C is the rule that > >makes procedures int by default. > > From today's point of view, yes, but before the advent of "void" > it was quite convenient. Of course it can't be changed now, due > to the amount of correct existing code that would be invalidated. Well, there is a way to change it now. Namely, an implementation could provide this feature (not defaulting functions to 'int') as an option. Of course, to be called an ANSI compiler, it would also have to have a way to turn off this behavior. Dave Wolverton ihnp4!houxs!daw