How to disable "curses.h" header (a part of "stdio.h in Xcode 6.3 OSX Yosemite) to avoid conflicting function declarations

Question

I'm trying to build a project in Xcode but I get the following errors Implicit declaration of function 'clear' is invalid in C99 and Conflicting types for 'clear'.

Here's the code:

//main.c
#include <stdio.h>
#include "tree.h"

int main(){
  clear(); // Implicit declaration of function 'clear' is invalid in C99
  return 0;
}

//tree.c
#include <stdio.h>
#include "tree.h"
void clear(){ ///Conflicting types for 'clear'
  printf("Command clear.\n");
}

//tree.h
#include <stdio.h>

void clear(); ///Conflicting types for 'clear'

Why do I get these errors and warnings? I've tried to search for the solution on StackOverflow, but all the related answers where about the case when there were no #include of some sort.

'clear' is not a keyword in C so it's not the case, is it?
(source: http://aboutc.weebly.com/keywords.html)

Related topics (do not answer my question although they are actually related):

• Implicit declaration of function 'sum' is invalid in C99
• Implicit declaration of function is invalid in C99

Thanks for any help.

---

UPDATE!

It turns out that changing the name of the clear funtcion to a cleark function solved the problem. Nevertheless it does not make any sense to me yet.

---

UPDATE 2!

I based my project on the command line tool template from Xcode 6.3 on Mac OS 10.10. Because of that Xcode has automatically added some libraries and flags to the project's compiler. What's the most important here is that the curses.h header has been added and this header already contains the clear() function.

Here's the Conflicting types for 'clear' error log: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/curses.h:541:28: Previous declaration is here

I've tried to remove the -lcurses from the compiler's flags manually, but I couldn't locate such settings. Is there any another way to build the project? (All in all my goal is to be able to use the Xcode's debugger when the project expands)

---

UPDATE 3! According to what Paul Griffiths discovered and published in the comment below the problem is following:

I can indeed replicate this problem with Xcode 6.3.1 with only the code presented. For some reason, stdio.h seems to be including curses.h (i.e. if you don't include stdio.h, this issue goes away), and I haven't been quickly able to find a way to stop it doing that. This seems to be problematic, since standard headers should not import random symbols into the global namespace without an easy and obvious way to turn it off.

Inwrap

The point is there is not much left to show - I can post the whole code if it's necessary but it is not complicated (just a bunch of more not yet implemented functions like add() or clear(). What's surprising is that only the clear() function throws the errors and warnings.. – Inwrap

Note: Interesting "changing the name of the clear funtcion to a cleark function". funtcion --> function – Rotative

The code you have posted does not cause the problem that you show. You will have to be more specific about your includes. Alternatively, you can just pick another function name and be done with it. – Stormystorting

The thing is it does not cause the problem if you compile it using standard gcc in terminal. It does cause the problem however when I'm trying to compile it in Xcode with a command line tool template loaded. – Inwrap

I can indeed replicate this problem with Xcode 6.3.1 with only the code presented. For some reason, stdio.h seems to be including curses.h (i.e. if you don't include stdio.h, this issue goes away), and I haven't been quickly able to find a way to stop it doing that. This seems to be problematic, since standard headers should not import random symbols into the global namespace without an easy and obvious way to turn it off. – Catechism

Answer 1

Normally I run the C preprocessor to see what the compiler actually parses. However, following Xcode Preprocessor Output to examine the preprocessor output with Xcode does not achieve that - it is translating the #include to @import. Here is what the preprocessor view shows me:

// Preprocessed output for tree.c
// Generated at 9:24:57 PM on Friday, May 1, 2015
// Using Debug configuration, x86_64 architecture for curses-vs-stdio target of curses-vs-stdio project

# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 322 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c" 2



# 1 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.h" 1


void clear(void);

@import Darwin.C.stdio; /* clang -E: implicit import for "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/stdio.h" */
# 5 "/Users/thomas/Desktop/curses-vs-stdio/curses-vs-stdio/tree.c" 2

void clear(void) {
    printf("Command clear.\n");
}

Apparently the problem is Xcode's use of modules rather than stdio.h including curses.h. The "Darwin" module is where the problem lies.

In fact, if I disable modules (using the hint in Enable Clang Modules, Disable Auto Linking), the build problem goes away. This is

• in Build Settings
• section Apple LLVM 6.1 - Language - Modules
• setting Enable Modules (C and Objective-C)

As a further hint to the problem, having rearranged the example slightly (putting the prototype before the include), I see a message complaining about overloading — but that is not C.

Perhaps Apple will fix this in the next release.

Butterfingers

Answer 2

You are including "trie.h", not "tree.h".

But maybe that's just you being careless when posting the code...

I bet there is another function named clear () defined somewhere. Possibly in your version of stdio.h.

Hydric

trie.h is not the issue. Sorry for being careless.. I'll check my stdio.h - maybe xcode has clear() inside. – Inwrap

after renaming the function clear the Xcode has finally been able to build the project. Why is it so? – Inwrap

The usual way to investigate this is to use the C preprocessor to make a file showing which files were included. With the given methodology, there is no useful information for a bug report to anyone. – Butterfingers