[open-cobol-list] Compile error in screenio.c: conflicting declarations (with fix)

[Scott McKellar]

Yesterday I tried to compile from gnu-cobol-1-1.tar.gz, freshly downloaded from 
SourceForge.  The make step failed when it tried to compile screenio.c.  After 
a little digging the problem became obvious.

screenio has two different definitions for cob_field_display() and 
cob_field_accept(), selected via conditional compilation (based, I think, on 
whether some appropriate version of curses is available).  The first pair of 
function definitions look normal.  They do stuff.  The second pair of function 
definitions, on the other hand, have empty bodies.  They are no-ops, presumably 
because if curses is not available, there's no way for them to do anything 
(except by re-implementing curses, which would be silly).

The problem is that the second pair of function definitions don't have the 
right signatures.

The first pair of definitions each have seven parameters.  The second pair, 
with the empty bodies, each have only six parameters.  The C compiler quite 
rightly complains that the function definitions don't match the prototypes in 
the associated header file.

Since these versions of the functions don't do anything anyway, I just added 
the missing parameters to the parameter lists, and then the build succeeded.

For what it's worth, I'm building on Kubuntu 10.4. using gcc, and the configure 
option --without-db.  I probably don't have the curses development package 
installed because I've never had occasion to use it.  That would explain why 
I'm getting the no-op versions of these functions.

In any case it doesn't really matter what my development environment is.  Just 
look at the code in screenio.c and you can see that it's wrong.

This problem was reported in this list by Dave Stratford on 2009-12-05, but no 
resolution was offered.  It was reported again by Haroldo Sotomayor Penroz on 
2010-04-14, but again there was no resolution (in fairness, the relevant error 
messages were buried in a very long post).

More recently, jean-max reymond opened bug #42 on 2012-10-23, citing the same 
errors that I got, but it was closed without a fix.


Scott McKellar