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

Question

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.

Answer 1

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.