gcc bug? Openoffice port impossibel to compile on 4.8

[Loren James Rittle]

In article <200305301727.06623.wes at softweyr.com> Wes Peters write:
>On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote:
>> Bruce M Simpson <bms at 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