scott scott - 1 month ago 3
C Question

C error: conflicting types for function and previous declaration was here (not duplicate)

Apologies for the dumb question. I checked all similar questions for the same error on stackoverflow, but it didn't help me understand why this error is happening in the following code.

I have one additional header file and a source file, which is included in the main file, and when I compile, I am getting the following error. I am trying to pass the

char** argv
from the
main()
to another function defined in another header file.

#include "include/Process.h"
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv) {
if (argc < 2) {
printf("Please provide a path to file\n");
return (EXIT_FAILURE);
}
Process(argv);


Process.h:

#pragma once
extern void Process(char** path);


Process.c:

#include <stdio.h>
#include "../include/Process.h"
#include <stdlib.h>
#include <sys/stat.h>
#include <syslog.h>
#include <sys/types.h>
#include <unistd.h>
void Process(char** path) {
printf("%s\n", path[1]);
}


It gets compiled but the warning is

./src/Process.c:22:6: error: conflicting types for ‘Process’
void Process(char** path) {
^
./include/Process.h:17:6: note: previous declaration of ‘Process’ was here
extern void Process(char** path);
^


However, the warning disappears when I change the type of
path
from
char**
to
char*
and pass
argv[1]
instead of
argv
.

I am clueless why this is happening like this, and according to
this similar post, I tried adding a forward declaration for
char** path
above
extern void Process(char** path);
in the
Process.h
file, but it didn't help either.


  • Why is this error thrown when using
    char** path
    ?

  • Why it disappears when I use
    char* path
    ?

  • So far, I am able to see the program running, even with this warning. Is it safe to ignore this warning? If not, what could be the possible effects it can have during runtime?



Using gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)

Thanks.

M.M M.M
Answer

Try putting your custom includes after the system includes.

It might be possible that the custom include defines a macro which interferes with the system includes. To minimize the risk of this, I always put the Standard C includes first, then any OS includes, and then third party libraries, and then my own ones

In theory the custom include shouldn't do this, and the system includes should only use reserved names, but in practice this doesn't always happen.