Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ihnp4!drutx!mtuxo!mtune!codas!peora!pesnta!wjvax!brett From: brett@wjvax.UUCP Newsgroups: comp.lang.c Subject: Re: Questions on X3J11 draft Message-ID: <780@wjvax.wjvax.UUCP> Date: Tue, 9-Dec-86 15:10:14 EST Article-I.D.: wjvax.780 Posted: Tue Dec 9 15:10:14 1986 Date-Received: Sun, 14-Dec-86 07:35:28 EST References: <351@danews.ATT.COM> <7373@utzoo.UUCP> <3800@watmath.UUCP> <775@axis.UUCP> Reply-To: brett@wjvax.UUCP (Brett Galloway) Organization: Watkins-Johnson Co., San Jose, Calif. Lines: 67 Keywords: C,X3J11 In article <775@axis.UUCP> philip@axis.UUCP (Philip Peake) writes: >In article <3800@watmath.UUCP> rbutterworth@watmath.UUCP writes: >> >>I can think of a perfectly conforming ANSI compiler that will break >>almost any existing C code. Imagine a piece of code such as the following: >> #include>> { >> extern int getchar(); >> auto int c; >> c=getchar(); >>At the moment, this will blow up on (all?) existing C compilers since >>"getchar" is a macro. Of course everyone KNOWS this and so never puts >>such things into their code. But under ANSI, almost any function can >>be defined as a macro in the header files. That means that almost >>any program that contains an "extern type libCfunc();" in it can >>potentially break under a conforming ANSI compiler. >> >>This change may or may not be a good thing; I don't know. >>I do know that my own coding style has changed drastically >>because of it. I used to put explicit extern statements for >>all the functions I use, simply to document the fact that I >>am using them. Now I NEVER put extern statements into ANY >>source.c file. > >This is a *very* good point ! (Why didn't I think of it ? ......) > >My personal coding style has changed considerably over the years, and >one of the directions in which it evolved was to ALWAYS put extern >declarations of any functions that I use. > >I started by putting them into a header file, this gets to be a pain, >since we either have a header file for each C file, or lots of redundant >extern declarations, and 'make' going beserk if you change one of the >declarations. > >I now put them into the C file - I think its cleaner, and I like to be able >to find the type of a function when I am looking at a piece of code. > >Taking the above example (sligthly modified), what if the function >actually returns something other than int ? > >You HAVE to put the extern definition, if not other things will >probably (certainly ?) break. > >How can I know, when trying to write portable code, if the 'library' >function I am going to use is a real function or a macro ? > Since the only case this appears is in library functions, many of which have header files anyhow (e.g. stdio), what is the cost of letting the header file for a package do the extern references for the functions available in that package (in BSD4.2, egs. curses.h, strings.h)? This does have the virtue of solving the problem, as was noted by the first poster. My real question is in implementation -- are there any loaders/compilers which (stupidly) link in text which is referenced in an extern but not used? If so, this method can lead to grossly wasteful binaries when you want to use only a few of the functions available in a package, but the header kindly declares all of them extern. I ask first to know if I am likely to be bitten by this with code that I have already written, and second possibly to influence any current standardization efforts to ban such behaviour by a loader/compiler. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett