\"Bug\" in 4.2 BSD C compiler...

[Jordan Brown]

> int usr1(), usr2(), usr3();

> int *procs[] = { usr1, usr2, usr3 };

Now what you have is an array of pointers to integers.

> Now, several people observed that

> int (*procs[])() = ...

> will work, and this is correct.  The question arises on the basis of K&R
> pp 114-115, which would seem to indicate that my declaration is acceptable
> on the grounds that pointers to integers and pointers to functions returning
> integers are supposed to be equationally indistinguishable.

I don't understand how you get this.  Is it the statement (pg 115) "since
they are known to be functions, the & operator is not necessary..."?  None of
the statements on pp 114-116 seem to imply anything of the sort.

> I don't want to make this a religious battle - I will use what works, but it
> did strike me as curious that three of the four C compilers I use regularly
> take this without complaint, and that the loser was 4.2BSD. Is this version
> right or wrong?

In the most global sense, it can't be right - there is no guarantee that
pointers are the same length, and in some very real cases they are *not*
the same length.  On an 8086 or 80286, it is entirely possible for pointers
to data to be 16 bits and pointers to functions to be 32 bits.  The entire
Xenix/286 kernel is compiled in this way.

However, since you request it... the SysV (R2 I think) compiler for the
AT&T 3B2 says

"foo.c", line 2:  warning:  illegal pointer combination, op =
"foo.c", line 2:  warning:  illegal pointer combination, op =

I presume that it automatically casts the pointers to (function returning
int) into pointers to ints.  It happens that this is possible on a 3B2.

As an aside, I'm curious whether K&R intended their words to be interpreted
so strictly, like laws or the Bible, where every nuance has deep philosophical
meaning.