CentOS and redhat

[qianz99]

I have a code. I can compile well in redhat. but when I swich to
CentOS
I ran into problems.
MAPlib.c:16: error: incompatible type for argument 1 of `log'

while my log is defined as
void log(FILE *fp,const char *fmt, ...)
{
if(!debugFlag) return;
va_list argp;
va_start(argp, fmt);
vfprintf(fp, fmt, argp);
va_end(argp);
}

What's the problem?

 

[Ben Pfaff]

I ran into problems.
MAPlib.c:16: error: incompatible type for argument 1 of `log'

"log" is a function in the standard C library. It computes and
returns the natural logarithm of its floating-point argument.

while my log is defined as
void log(FILE *fp,const char *fmt, ...)
{
if(!debugFlag) return;
va_list argp;

Only in C99 may declarations follow statements within a block.

va_start(argp, fmt);
vfprintf(fp, fmt, argp);
va_end(argp);
}

Attempting to define your own externally visible function named
"log" invokes undefined behavior. I'd suggest renaming your
function.

 

[Clever Monkey]

I have a code. I can compile well in redhat. but when I swich to
CentOS
I ran into problems.
MAPlib.c:16: error: incompatible type for argument 1 of `log'

while my log is defined as
void log(FILE *fp,const char *fmt, ...)
{
if(!debugFlag) return;
va_list argp;
va_start(argp, fmt);
vfprintf(fp, fmt, argp);
va_end(argp);
}

Probably off-topic given the subject, but it may be that log() is not in
scope, or you are passing it something other than a FILE. Since you
show no relevant code, it's hard to tell.

Can you reduce the problem to the smallest reproduceable (i.e.,
compilable) case?

 

[Richard Tobin]

MAPlib.c:16: error: incompatible type for argument 1 of `log'

There's a standard C function called log, for logarithms.
Unfortunately that means you have to call your function something
else.

-- Richard

 

[Clever Monkey]

There's a standard C function called log, for logarithms.
Unfortunately that means you have to call your function something
else.

D'oh! Of course.

 

[CBFalconer]

I have a code. I can compile well in redhat. but when I swich to
CentOS I ran into problems.
MAPlib.c:16: error: incompatible type for argument 1 of `log'

while my log is defined as
void log(FILE *fp,const char *fmt, ...)
{
if(!debugFlag) return;
va_list argp;
va_start(argp, fmt);
vfprintf(fp, fmt, argp);
va_end(argp);
}

What's the problem?

Move the declaration of va_list up one line.

 

[Keith Thompson]

Move the declaration of va_list up one line.

And why would you expect that to solve "error: incompatible type for
argument 1 of `log'"?

Yes, he should move the declaration of argp up a line if he doesn't
want to depend on either a C99 compiler or a C90 compiler with
extensions, but the real problem seems to be a name collision with the
"log" function declared in <math.h>.

 

[Barry Schwarz]

I have a code. I can compile well in redhat. but when I swich to
CentOS
I ran into problems.
MAPlib.c:16: error: incompatible type for argument 1 of `log'

while my log is defined as
void log(FILE *fp,const char *fmt, ...)
{
if(!debugFlag) return;
va_list argp;
va_start(argp, fmt);
vfprintf(fp, fmt, argp);
va_end(argp);
}

What's the problem?

The error message probably relates to the statement that calls log.
The code you have shown only has parameters, not arguments. We also
need to see the prototype, if any, for log before the function is
defined (in case the compiler diagnostic is using less than precise
terminology).


Remove del for email

 

[Barry Schwarz]

"log" is a function in the standard C library. It computes and
returns the natural logarithm of its floating-point argument.


Only in C99 may declarations follow statements within a block.


Attempting to define your own externally visible function named
"log" invokes undefined behavior. I'd suggest renaming your
function.

And to clever monkey, Richard Tobin, and Keith Thompson: There is no
indication that his program contained a #include<math.h> directive.
Without it, there would be no prototype in scope for the standard log
function and the compiler should not be able to match the calling
statement or this function definition to that standard function. A
linker message regarding multiply defined functions with the same name
or a run time error (including any type of undefined behavior) because
the wrong function was called should be the worst that this situation
could produce. A compile time error about argument mismatches just
doesn't seem to flow from this situation.


Remove del for email

 

[Keith Thompson]

And to clever monkey, Richard Tobin, and Keith Thompson: There is no
indication that his program contained a #include<math.h> directive.
Without it, there would be no prototype in scope for the standard log
function and the compiler should not be able to match the calling
statement or this function definition to that standard function. A
linker message regarding multiply defined functions with the same name
or a run time error (including any type of undefined behavior) because
the wrong function was called should be the worst that this situation
could produce. A compile time error about argument mismatches just
doesn't seem to flow from this situation.

Since log is a predefined function, the compiler may know about it.
I've seen compilers (or at least one) use such knowledge to optimize
certain calls, or to diagnose invalid format strings for printf.
Since the code failed to compile, there was no opportunity for a link
error to appear.

Since the OP didn't show us a complete program, it's entirely possible
that <math.h> is included, either directly or indirectly. It's also
not clear that the declaration for the OP's own log function was
visible at the point of the call.

And the function's name needs to be changed anyway.

 

[Richard Tobin]

Since the OP didn't show us a complete program, it's entirely possible
that <math.h> is included, either directly or indirectly.

Since the OP said that the behaviour changed when switching between
operating systems, my guess would be that one of them indirectly
includes <math.h> and the other doesn't.

-- Richard