NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/gnu/gcc/bug/2263

Text File | 1992-09-07 | 3.7 KB | 97 lines

Newsgroups: gnu.gcc.bug
Path: sparky!uunet!cis.ohio-state.edu!skipsun.UUCP!skip
From: [e-mail] (Skip Gilbrech)
Subject: Re: Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: GNUs Not Usenet
References: <[e-mail]>
Distribution: gnu
Date: Sat, 5 Sep 1992 01:16:17 GMT
Approved: [e-mail]
Lines: 83

You write:

>    What I would really like to do, is turn off builtin functions, and the
>    builtin function prototypes.
>
>This is the wrong approach, for a basic philosophical reason.
>
>You have found a feature which, in a particular case, fails to work.
>To think that the solution is to turn off the feature is to assume
>that it can *never* work.
>
>But it is absurd to assume that.  We don't know why it does not work.
>It may be failing for a trivial reason.  It is silly to give up on the
>feature without first checking the possibility that it can easily be
>fixed.
>
>I can't tell you what to do.  Those of you who wish to give up on a
>feature can do so.  But for those of you who are interested in what I
>have to say, I urge you to take a constructive approach and help get
>things fixed.
>
>See the Bugs chapter of the GCC manual for a general guide to how to do this.
>
>In the case of a type conflict with a built-in function, the main
>useful thing for you to do is to find the declaration that conflicts
>and tell us precisely what data types the conflicting declaration
>uses.  Most importantly, find out what size_t is in the system headers.


Yes, but not everyone has the time, inclination, or expertise to find
and fix such conflicts, and even when they do, their only practical
option may be to make local copies of screwed-up system headers, most
often for extremely trivial conflicts that will have absolutely no
effect on the generated code.

And anyway, do you really want each of the thousands of people who
will encounter conflicts on Sun's, for instance, to send in a report
telling you (again..) how size_t is (mis-)declared?  This might be
reasonable on obscure systems, but the point is that the inconvenience
caused by these conflicts persists for many people _long_ after the
cause is well known.

To me, it seems largely an issue of dictating choices versus allowing
the user to decide what tradeoffs are important to her/him: the
advantages offered by built-ins may or may not be significant in a
given situation, but as it is now, there's no easy way to avoid
dealing with their downside regardless...

For these and other reasons, I would really appreciate (as would I'm
quite sure many others) a command-line _option_ to totally disable
built-in functions (and their prototypes).

Whatever is decided on that issue, though, gcc conflict warnings would
be much more useful if they gave a hint as to what conflicts with
what.  Given a bogus declaration like:

        double memcpy(int, char *);

for instance, gcc, when wearing its `c' hat, says:

Goo.c:5: warning: conflicting types for built-in function `memcpy'

but doesn't say what it's looking for!  How is one supposed to resolve
that conflict without searching through the gcc source and
configuration files, etc.?

g++ at least puts out some useful information before choking:

Goo.cc:5: declaration of `double  memcpy (int, char *)'
<built-in>:0: conflicts with built-in declaration `void * memcpy (void *, const void *, unsigned int)'

Any reason gcc in `c' mode can't be as forthcoming?


-Skip

--
Skip Gilbrech            email:    [e-mail]
Fusion Systems Group            uupsi!fsg!skip
225 Broadway, 24th Floor        uupsi!skipnyc!skip
New York, NY 10007        phones:    212-285-8001 (work)
                    201-825-8732 (home)