More Pointers ... (bug in gcc error checking)

[Wayne Throop]

> karln at uunet.uu.net
> Something bothers me about this example program. [...]
> main() {
>     int Board[3][3];
>     init_board( Board );
>     show_board ( Board );
> }
> init_board ( Board )
>     int (*Board)[3][3];
> { [...] (*Board)[i][j] = 0; [...] }
> show_board( Board )
>     int (*Board)[3][3];
> { [...] (*Board)[i][0], (*Board)[i][1], [...] }

Well, I'd tend to predeclare init_board and show_board, or place
main after their definitions.  But that's a minor nit.  More of a
problem are the things lint finds wrong here:

    t.c
    ==============
    Warning: (9)  main() returns random value to invocation environment
    ==============
    function argument ( number ) used inconsistently
        init_board( arg 1 )         t.c(12) :: t.c(6)
        show_board( arg 1 )         t.c(22) :: t.c(8)
    function returns value which is always ignored
        printf

In particular, passing something of type (int [N][M]) to something
of type (int (*)[N][M]) is a no-no (as is falling off the end
of an int-returning function).    

Most disressing to me is that gcc -Wall -ansi -pedantic didn't
diagnose this problem.   "Bzzzzzt!!  Thanks for playing our game, gcc..."

As to the specific example, I'd do it so:

    init_board ( Board )
        int Board[3][3];
    { [...] Board[i][j] = 0; [...] }
    show_board( Board )
        int Board[3][3];
    { [...] Board[i][0], Board[i][1], [...] }
    main() {
        int Board[3][3];
        init_board( Board );
        show_board ( Board );
    }

Further ideas: typedef-ing the board type, or the use of (int [][N])
formal argument types (equivalent to (int (*)[N]) formal argument types,
but ONLY as a formal argument type, NOT anywhere else!!!). 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw