How to disable support for C99 extensions / force compatability with C89?

How to disable support for C99 extensions / force compatability with C89?

• kachh

  For one of my projects, I'm forced to use C89 simply because of cross-platform compatibility -- gcc 2.8.2 didn't support C99 extensions, and about half of the users of this software need to use it on older platforms that later versions of GCC don't properly support.  Since I have to use the same source base for Windows, I'm stuck between a rock and a hard place.

  So, I'm stuck with another problem: how do I tell cl.exe that 'declaring a variable in a block after any code has been generated in that block is an error'   Does /Za do this

  
  

• Twisted Hardware

  I've just happened upon this thread while trying to find out about C standards compliance in Microsoft compilers and I have to say this is one of the the most ignorant, arrogant, head-in-the-sand posts about the matter that i've had the displeasure to see in a long while - inexcusable from someone who should know better (although that might go someway to explain the headaches many of us face in the real world when porting standards compliant code of various ages to Microsoft compilers)
  
  If people need to compile against a standard - what is wrong with supplying a switch to allow them to do so Is C89 dead .. you don't want to support it any more That might be a argument (not a very good one from a vendor/ISV point of view though) but when, exactly, did you support it properly anyway - perhaps that might have been something to do instead of moving onto the new standard which, by your own words, you are only going to support a couple of features from. You are not being pedantic in my view; that might have prompted some inclination to support - as fully and correctly as reasonably possible - standards that our used in the industry by many people - you are, I feel, being short-sighted and blinkered.
  
  I know this post is a while old but it really is an eye-opener - speaking as a professional programmer this reply, and what it implies, is disgraceful. I can only hope this sort of attitude is no-longer prevelant in the compiler team.
  
  Tim
  

• koranke

  For Visual C++ 2005 we have added what we think are the most useful C-99 features, "long long" and variadic macros, we will add other features as users request them. To be honest very few of our users (and I talk to a lot of them) know much about C-99. They know, and care, much more about the recent TR-1 for the C++ Standard and the future work that is going on for C++-0x.
  
  Our work in the area of Standard conformance (in both C and C++) really is driven by our customers: so if there is a C-99 (or C++) feature that you really think we need to support then please let me know.
  
  

  
  
  

• rseeders

  There are only two C-99 features that I know of in Whidbey Beta-2.
  
  Support for "long long" - which is really just a synonym of the existing __int64 type.
  Support for variable-argument macros.
  
  There is not a switch to disable these features and there shouldn't be. Maybe I'm being pedantic but C-89 is dead: when a new Standard is created (in no matter what field) old Standards are immediately obsoleted - after all you wouldn't want there to be two Standards.
  
  Having said that it is extremely unlikely that you'd run into these features if you are just doing a school project.
  
  

• DineshSharma

  In my experience a lot more people target/use C-89 then use C-99.
  
  We've actually supported C++ single-line comments in C for years. It was one of the earliest requests that our users made: people who had made the migration to C++ but then went back to C found the lack of C++ single-line comments annoying so we added support for them.
  
  You can disable them (or at least cause them to generate a diagnostic) but it is slightly complicated:
  
  1) You need to compile with the /Za - this is our strict mode (and it works better in C code than it does in C++). If you really want portability between compilers then this is probably a good option to use - especially if you are using C.
  
  2) You need to enable warning C4001 as it is usually disabled. To do this you can either add a #pragma to your code:
  
  #pragma warning(1:4001)
  
  or add the /w14001 option to the command-line.
  
  3) If a warning isn't strong enough for you then you can make this warning an error: either compile with /WX (this makes all warnings errors) or add this pragma to your code:
  
  #pragma warning(error:4001)
  
  or add /we4001 to the command-line.
  
  

• vurdlak

  The only other thing I have run into is the support for C++ style comments.  It doesn't seem possible to use the Comment Selection command if you want to maintain compatability with C89 - i'm not sure what portion of your customer base actually targets C89 (C in general definately feels like a 2nd-class citizen in visual studio), but perhaps disabling C99/C++-style comments with this command would be the safe thing to do here. 
  
  For what it's worth, I can tell you why we are using C89.  We're using it because of the varying support in different compilers, as there is a emphasis on portability of code for this course that i'm in (U. Michigan engineering school).
  
  

• CraigAP

  Jonathan,
  
  So why in the heck doesn't Microsoft support the C99 standard  
   
  

  
  
  

• Manitra

  Visual C++ 2005 (and all earlier versions) do not support this C-99 feature. So you don't need to do anything (other than to ensure you are compiling the file as a C file). For example:

  void f(int i)
  {
      int j = 0;

      j += i;

      int k = j + 2;
  }

  Compiling this gives:

  a.c
  a.c(7) : error C2143: syntax error : missing ';' before 'type'
  

   

  
  
  
• How to disable support for C99 extensions / force compatability with C89?