1

Apparently in .c files visual studio auto generates declarations for unidentified symbols. I tried using printf() without including stdio.h, as well as calling some random asd() function and it compiled without errors, only warnings appeared that compiler assumes extern returning int. To be sure I compiled assembly output and it really had those extern declarations. Of course linking was unsuccessful.

My question is, how can I turn off this auto generation of declarations for unidentified symbols? I have some project to do and it could kinda screw me up.

  • _compiler assumes extern returning int_ means the compiler does not have definitions for the functions you are trying to call. If you include the headers required for the calls you are using, AND the definitions for each function are visible to your environment, (i.e. the run-time environment such as: msvcr100.dll, some version of which is included in Visual Studios) your build will occur without errors, and without those particular warnings. – ryyker Aug 04 '14 at 20:45
  • @ryyker OP already stated in the question everything that you just said. – Jashaszun Aug 04 '14 at 20:47
  • 1
    @Jashaszun - read it again. _tried using printf() without including stdio.h_. Which means the compiler does not have the information it needs. C assumes `int`, and therefore extern defined in the warning, but build will fail. – ryyker Aug 04 '14 at 20:50
  • @ryyker Umm... yes. He compiled without `stdio.h`, which is why he expected to get errors, not just warnings. – Jashaszun Aug 04 '14 at 20:51
  • Post an ***[sscce](http://sscce.org/)*** ...relevant code, and the compile string. – ryyker Aug 04 '14 at 20:54

2 Answers2

3

This is compiler warning C4013.

http://msdn.microsoft.com/en-us/library/d3ct4kz9.aspx

You can set up your compilation command with the /we flag to treat that specific warning as an error.

http://msdn.microsoft.com/en-us/library/thxezb7y.aspx

/we n Treats as an error the compiler warning that is specified in n. For example, /we4326 flags warning number C4326 as an error.

If you want to get really conservative, you can just treat all warnings as errors. Many teams/projects consider this a best practice.

/WX Treats all compiler warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects. The linker also has a /WX option. See /WX (Treat Linker Warnings as Errors) for more information.

Chris Nauroth
  • 9,614
  • 1
  • 35
  • 39
  • This will be fine workaround, thanks. But is there a way to actually turn off this feature completely? – instancedName Aug 04 '14 at 20:51
  • 1
    In which way does using `/we4013` not disable this feature completely? – Ross Ridge Aug 04 '14 at 21:13
  • 1
    @instancedName - More importantly, why would you want to _turn off_ such a useful and informative feature of your compiler. (note, this is nothing more than the compiler telling you something is wrong. It is _not_ an _auto_generation_ feature of Visual Studios) – ryyker Aug 04 '14 at 21:43
1

Apparently in .c files visual studio auto generates declarations for unidentified symbols
This is not a correct conclusion.
It is not a Visual Studio problem. It is simply a warning from your compiler describing the assumptions it is making about a function in the absence of any real definition.

From HERE:

When you call a function with no prototype, some C compilers make assumptions about the function being called:

Function's return type is assumed to be int
All parameters are assumed to be declared (i.e. no ... vararg stuff)
All parameters are assumed to be whatever you pass after default promotions, and so on.   

If the function being called with no prototype fits these assumptions, your program will run correctly; otherwise, it's undefined behavior.

And from HERE:

If one doesn’t specify the function prototype, the behavior is specific to C standard (either C90 or C99) that the compilers implement. Up to C90 standard, C compilers assumed the return type of the omitted function prototype as int. And this assumption at compiler side may lead to unspecified program behavior.

To solve the problem you are seeing, it is not necessary (nor will it solve the stated problem) to change anything in Visual Studios, rather include the header files appropriate to the functions you are using.

Community
  • 1
  • 1
ryyker
  • 22,849
  • 3
  • 43
  • 87