• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
TheComet

std c89 not working with gcc?

6 posts in this topic

Hi

 

The following code compiles using gcc with std=c89, even though it shouldn't.

int main( int argc, char** argv )
{
        int a = 2;
        if( a == 0 )
                return 0;
        int b = 4;
        return 0;
}

I'm developing software that strictly requires to follow the c89 standard, which states that all declarations must be at the beginning of the respective block. Why is gcc ignoring this? This is how I invoke gcc:

$ gcc -std=c89 -W -Wall -Wextra -o test main.c

Compiling the same code using Visual Studio 2010's nmake produces the correct errors.

 

0

Share this post


Link to post
Share on other sites

There is no ability to check for strict C89 compliance with gcc. From gcc's docs:

"Some users try to use -Wpedantic to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all—only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added." (http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)

 

For Visual Studio, /Za disables extensions. I'm not sure how close that gets you to strict C89, but be aware you can't even include windows.h when specifying /Za.

 

I don't really understand how you're in this situation though. If you're working for someone else who is requiring the strict C89 compliance, they should tell you what compiler and settings are used for the release builds. And how else would you be required to have strict c89 compliance than working for someone demanding it?

2

Share this post


Link to post
Share on other sites

Thanks for the info.

 

The problem is finding common ground between all of the compilers. The project is supposed to be cross-platform, and is mainly being developed on Windows using vc10 (which, I was told, follows the C89 standard pretty strictly). I was hoping I would be able to develop it on my linux machine, serving as the developer for linux line endings, but gcc is extremely loose and forgiving.

 

I do have the option of developing it in a VM with Windows and vc10 if I have to.

 

For now, I'm using the following flags. They appear to do the job:

-std=c89 -W -Wall -Wextra -pedantic -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition

I've also read that some warnings are only available when using the optimizer, e.g. -O3

 

----

 

I feel this is a general issue with gcc: It's extremely loose with everything, and not just C code. I've seen it compile C++ code that clang or MSVC will spit back. In fact, rapidxml is such an example; it will only compile under gcc and not clang or MSVC.

 

Is clang perhaps a better tool for this situation?

0

Share this post


Link to post
Share on other sites

I feel this is a general issue with gcc: It's extremely loose with everything, and not just C code. I've seen it compile C++ code that clang or MSVC will spit back. In fact, rapidxml is such an example; it will only compile under gcc and not clang or MSVC.


At least in the C++ world, my experience has been exactly the opposite. MSVC compiles C++ code (especially looking at templates here) which it never should according to the standard. Especially when telling gcc to be sufficiently pedantic, writing standard-conforming code with gcc is far easier.
I have been working on a project which was built both on Windows (MSVC) and Linux (gcc) in the past. Usually compilation problems originated in Windows programmers, extremely seldom the other way around.

I don't have enough experience with clang to comment on it, but according to my last information, clang on Windows was still not reliable enough to risk using it an production system.

I'd be interested to know what exactly is the problem with rapidxml. Is it possible the library detects C++11-capable compiler and fails because MSVC only supports a rather pitiful part of that?
0

Share this post


Link to post
Share on other sites

I should have considered cross-platform tools development, especially since you mentioned C instead of C++. For that, the language standard is irrelevant. As you correctly recognize, you're really interested in the common ground between compilers instead of the language. To do that, you can set up a build process that builds using as many compilers as possible to try to catch violations. Use -Wpedantic and the equivalent in other compilers. Work around the Visual Studio problems like Microsoft-supplied headers generating warnings, and then avoid adding any warnings from your code. If you're providing headers for others to include, you need to do this since developers often judge your tool on its ability to avoid generating warnings.

 

I'm surprised to hear rapidxml doesn't compile on Visual Studio since they used to explicitly test that it does compile on Visual Studio (excluding VS6 obviously).

 

Clang is better at standards compliance and more descriptive with errors, so it might be worth using. I wouldn't use the executables generated by Clang without testing performance though, as they still have a few extremely weak areas.

1

Share this post


Link to post
Share on other sites
I'm surprised to hear rapidxml doesn't compile on Visual Studio since they used to explicitly test that it does compile on Visual Studio (excluding VS6 obviously).

I just tested rapidXML using g++, clang++, and MSVC, and it appears they patched it.

 

The bug I was talking about was: http://sourceforge.net/p/rapidxml/bugs/16/

 

The patch we used to fix it back then was:

@@ -100,7 +100,21 @@
         }
 
         ///////////////////////////////////////////////////////////////////////////
-        // Internal printing operations
+        // Internal printing operations
+    
+        // =====================================
+        // fix for clang for this bug in gcc and others: http://sourceforge.net/p/rapidxml/bugs/16/
+        // would compile with gcc, but not with clang
+
+        template<class OutIt, class Ch> inline OutIt print_children(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_element_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_data_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_cdata_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_declaration_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_comment_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_doctype_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+        template<class OutIt, class Ch> inline OutIt print_pi_node(OutIt out, const xml_node<Ch> *node, int flags, int indent);
+
+        // =====================================

         // Print node
         template<class OutIt, class Ch>

rampidXML would compile in gcc but not in clang, because some templated functions were depending on other templated functions that were not declared yet. I guess you could say that gcc was "smart enough" to apply some kind of post-lookup to fix this, but the reality is that the code was incorrect.

 

It's things like that that I'm worried about with this project.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0