cmacoscursescompiler-flagsxcode6.3

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


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):

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.


Solution

  • 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

    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.