C function pointer problems

[Ben Cotton]

One of my users is having problems with some C code she needs to compile (below). When gcc tries to compile, it complains about "dereferencing pointer to incomplete type." It's been a while since I've done anything in C and pointers were always my weakness. Can anyone shed some light on what the problem is?

static char SccsId[]="@(#)itime.c 1.1 5/21/93";

/*
* function to return date (YYMMDD) and time (HHMMSS)
*/

#include <math.h>
#include <sys/time.h>
#include <sys/types.h>

int itime_(date,ltime)
int *date, *ltime;

/* USAGE: iseconds = itime_(date,ltime)
* FORTRAN-callable function that returns the current date and time
* in integer words, in the format YYMMDD and HHMMSS where
* YY is the year (modulus 100), MM the month, DD the
* day of the month, HH the hour, MM minute, SS second. The
* function also returns the number of seconds since the start of the
* current date, as 'iseconds'. (After calling, the structure pointed
* to by *lt also contains some other useful results, like
* Julian day, day of the week, etc.)
*/
{
struct tm *localtime();
struct tm *lt;
int ltarray[50];
int seconds;
time_t clock;
time_t *tloc;
time_t time();

tloc = 0;
clock = time(tloc);
lt=localtime(&clock);
*date = 10000*((*lt).tm_year%100)+ 100*((*lt).tm_mon+1) + (*lt).tm_mday;
*ltime = 10000*((*lt).tm_hour)+ 100*((*lt).tm_min) + (*lt).tm_sec;
seconds = 3600*((*lt).tm_hour) + 60*((*lt).tm_min) +(*lt).tm_sec;
return seconds;
}

[GNU-Fan]

Please be verbatim when you report compiler errors. (Usually there is a line number which gives a first hint where the error is, so the person helping you does not have to parse the complete code).

That being said, struct tm *localtime(); looks suspicious to me. (i.e. the brackets)

EDIT: The whole program looks a bit strange to me. It seems to be written in a dialect which has been outdated for 30 years or so. If you got it somewhere else, my recommendation is to rewrite it from scratch in standard compliant C. I don't know if there are modern compilers which still can compile this.

[Ben Cotton]

Here's the full output from gcc

itime.c: In function ‘itime_’:
itime.c:36: error: dereferencing pointer to incomplete type
itime.c:36: error: dereferencing pointer to incomplete type
itime.c:36: error: dereferencing pointer to incomplete type
itime.c:37: error: dereferencing pointer to incomplete type
itime.c:37: error: dereferencing pointer to incomplete type
itime.c:37: error: dereferencing pointer to incomplete type
itime.c:38: error: dereferencing pointer to incomplete type
itime.c:38: error: dereferencing pointer to incomplete type
itime.c:38: error: dereferencing pointer to incomplete type

[GNU-Fan]

I just added some text to my former post.

Again, I do not know which compiler accepts such oldish style. You are probably better of to rewrite it from scratch.

[Rubberman]

I just added some text to my former post.

Again, I do not know which compiler accepts such oldish style. You are probably better of to rewrite it from scratch.

I would agree. This code is very much bogus. What happens if an invalid pointer is passed for the date or ltime parameters to the function? Since it never validates them, or checks for null, this is a core dump waiting to happen. Also, the declaration of local_time() inside the body of the function is in the old pre-ansi standard format (early K&R C coding) without any argument types specified, yet it is called with arguments. This will cause modern compilers to complain. In any case, when you post code here that gives errors on compiling, please post the actual compiler output since, as GNU-fan noted, it will give a line number of the offending code - or at least as close as it can determine. Since it thinks that the struct tm* lt is only partially defined, I think you need to #include <time.h> instead of <sys/time.h>, as struct tm is defined there.

[aram535]

Agreed 100% with the above.

In addition, I suggest some debugging practices. As in such cases, break down the line that is giving the error into multiple vars. You'll have more luck narrowing down the offending statement than trying to decipher and debug at the same time.