Questions on X3J11 draft

[brett at wjvax.UUCP]

In article <775 at axis.UUCP> philip at axis.UUCP (Philip Peake) writes:
>In article <3800 at watmath.UUCP> rbutterworth at 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 <stdio.h>
>>    {
>>        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