Re: gcc bug? Openoffice port impossibel to compile on 4.8

From: Loren James Rittle (rittle_at_latour.rsch.comm.mot.com)
Date: 06/03/03

  • Next message: Terry Lambert: "Re: sendfile in FreeBSD 2.2"
    Date: Mon, 2 Jun 2003 22:36:17 -0500 (CDT)
    To: freebsd-hackers@freebsd.org
    
    

    In article <200305301727.06623.wes@softweyr.com> Wes Peters write:
    >On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote:
    >> Bruce M Simpson <bms@spc.org> writes:
    >> > However, we're dealing with something a bit more stable in terms of
    >> > code base, anyway. Having to commit a whole bunch of fixes for the
    >> > sake of a compiler upgrade isn't acceptable. Sounds like the GCC
    >> > guys have been bitten by the Linux bug.

    >> May I remind you that K&R-style declarations have been deprecated for
    >> the last 14 years?

    > Funny, the last time I looked at a C language specification they were
    > still supported.

    Guys, can we up the technical information content for -hackers and
    remove this silly "bitten by the Linux bug" and the red-herring of gcc
    removing support for K&R decls (of course, it hasn't; and, of course,
    there are many gcc hackers that are making sure really old code will
    still compile with gcc X.Y)? There was a posted claim on -hackers
    that modern gcc does something funky with K&R decls of this form
    (i.e. complete side issues to the crash that started the thread):

    int
    foo(a)
      struct bar* a;
    {
      return 0;
    }

    Or, that it does something funky at the point of invocation of said
    function. In fact, here is the full short test case (and, yes, there
    is no switch in gcc to disable this warning, now 14 years after C89
    suggested that it be issued by compilers implementing the standard):

    struct bar { int a; int b; } dapper;

    static int
    foo(a)
      struct bar* a;
    {
      return 0;
    }

    void zapper (void)
    {
      foo ((char *) &dapper);
    }

    The *warning* emitted by gcc when enough analysis is done (e.g.
    "-O -finline-functions" or -O3):

    j.c:6: warning: passing arg of `foo' from incompatible pointer type

    is in no way related to the use of K&R decls (make the above test case
    use ISO decl form and you will see it always appear). It is related
    to stupid pointer tricks, or rather catching when a programmer used
    one (BTW, the explicit cast to char* is not the stupid pointer trick
    to which I refer here). The 14-year old standard (and drawn from
    convention going back years before that) says that you may cast to
    void* and back to struct foo* without any problems. It does not say
    the same thing about casting to char* and then back to struct foo* but
    gcc probably will do the "right" thing in that case for most CPUs.

    Now, had the above been a hard error, I could understand a position
    that the gcc team doesn't care about old code, etc. But, in fact, it
    is a report of a legitimate portability issue. (And, ironically is
    only ever reported when in inline mode for functions with K&R-style
    decls. Thus, I think someone had a knowing sense of humor if they
    arranged for that to happen but I don't remember the discussion.)

    BTW, in case you still don't understand the stupid pointer trick being
    caught, the following code has a similar issue and warning with
    absolutely no switch to disable it:

    struct bar { int a; int b; } dapper;

    void zapper ()
    {
      struct bar *foo = (char *) &dapper;
    }

    j.c:5: warning: initialization from incompatible pointer type

    How many of you on -hacker really want a switch to allow the above
    code to compile without any warning? I think it is folly, but if
    enough -hackers say "By god, I'm smarter than the compiler (hi, Terry)
    and when I fail to give a cast, damnit I want the compiler to know it
    (humm, it seems we have walked into a logical paradox now since the
    compiler has to be smart enough to know that since you didn't give the
    cast, it had to guess at one to logically insert which is precisely
    what it did when it reports that non-optional warning)", then we can
    add the two lines of code.

    Regards,
    Loren
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


  • Next message: Terry Lambert: "Re: sendfile in FreeBSD 2.2"

    Relevant Pages

    • xemacs installation problems
      ... checking for gcc... ... checking whether we are using GNU C... ... checking size of int... ... configure: warning: No OffiX without generic Drag'n'Drop support ...
      (comp.os.linux.misc)
    • Re: How to check if same partition
      ... GCC will bitch when you get this wrong. ... function(int b, int c, int something) ... The gcc version I am using is clever enough not to give this warning ... I covered all cases for argc. ...
      (comp.os.linux.development.apps)
    • Help needed in solving C-errors in Linux (gcc)
      ... i'm trying to make I got the following messages from gcc. ... main.c:22: warning: comparison is always false due to limited range of data type ... int conv_inch2feet; ... int convert(int unit, const char *,const char *,const char *); ...
      (alt.os.linux)
    • Help needed in solving C-errors in Linux (gcc)
      ... i'm trying to make I got the following messages from gcc. ... main.c:22: warning: comparison is always false due to limited range of data type ... int conv_inch2feet; ... int convert(int unit, const char *,const char *,const char *); ...
      (comp.os.linux.development.apps)
    • pointers to incompatible types
      ... int main ... Which, with gcc, yields: ... dec.c:3: warning: `struct bar' declared inside parameter list ... * baz); ...
      (comp.lang.c)