[SOLVED] Do we have c99 subflags

Do we have c99 subflags

Are there sub-options provided for -std=c99, so that i can pass those sub-options and get away from passing -std=c99?

For example:

int main()
{
    for(int i=0;i<10;i++)
    {
        i++;
    }
    return 0;
}

I would to compile this code with gcc by passing any sub-options.

$ gcc -sub-option-for-c99 a.c

Thanks

Edit: I want to pick just a single feature from C99, while keeping the rest of the compiler in C89 (or some other) mode.

Solution

C99 didn't have much provision for sub-setting the functionality (essentially no sub-setting). C11 does have some provision for that. However, the details of what is implemented tends to be controlled by the implementation, rather than something the programmer can change other than by an overall switch such as -std=c11 or -std=gnu11. That's a long-winded way of saying "No".

Example of sub-setting in C11: Annex K (previously TR 24731-1) Bounds-Checking Interfaces.

A program can indicate that it wants to use the facilities by defining __STDC_WANT_LIB_EXT1__, but that won't help you if the implementation does not itself define __STDC_LIB_EXT1__.

A more complete list of sub-setting from ISO/IEC 9899:2011 (with Corr.1 applied to the value of __STDC_LIB_EXT1__):

6.10.8.3 Conditional feature macros

¶1 The following macro names are conditionally defined by the implementation:

__STDC_ANALYZABLE__ The integer constant 1, intended to indicate conformance to the specifications in annex L (Analyzability).

__STDC_IEC_559__ The integer constant 1, intended to indicate conformance to the specifications in annex F (IEC 60559 floating-point arithmetic).

__STDC_IEC_559_COMPLEX__ The integer constant 1, intended to indicate adherence to the specifications in annex G (IEC 60559 compatible complex arithmetic).

__STDC_LIB_EXT1__ The integer constant 201112L, intended to indicate support for the extensions defined in annex K (Bounds-checking interfaces).¹⁷⁹⁾

__STDC_NO_ATOMICS__ The integer constant 1, intended to indicate that the implementation does not support atomic types (including the _Atomic type qualifier) and the <stdatomic.h> header.

__STDC_NO_COMPLEX__ The integer constant 1, intended to indicate that the implementation does not support complex types or the header.

__STDC_NO_THREADS__ The integer constant 1, intended to indicate that the implementation does not support the <threads.h> header.

__STDC_NO_VLA__ The integer constant 1, intended to indicate that the implementation does not support variable length arrays or variably modified types.

¶2 An implementation that defines __STDC_NO_COMPLEX__ shall not define __STDC_IEC_559_COMPLEX__.

¹⁷⁹⁾ The intention is that this will remain an integer constant of type long int that is increased with each revision of this International Standard.

See also section 6.10.8 Predefined macro names generally for related information.

Note that these macros are defined or not defined by the implementation depending on what it does or does not support. It won't make any difference if you try to set them yourself; they are intended for the implementation to communicate with you, not vice versa.

ISO/IEC 9899:1999 §6.10.8 Predefined macro names

¶2 The following macro names are conditionally defined by the implementation:

__STDC_IEC_559__ The integer constant 1, intended to indicate conformance to the specifications in annex F (IEC 60559 floating-point arithmetic).

__STDC_IEC_559_COMPLEX__ The integer constant 1, intended to indicate adherence to the specifications in informative annex G (IEC 60559 compatible complex arithmetic).

__STDC_ISO_10646__ An integer constant of the form yyyymmL (for example, 199712L), intended to indicate that values of type wchar_t are the coded representations of the characters defined by ISO/IEC 10646, along with all amendments and technical corrigenda as of the specified year and month.

¶3 The values of the predefined macros (except for __FILE__ and __LINE__) remain constant throughout the translation unit.

¶4 None of these macro names, nor the identifier defined, shall be the subject of a #define or a #undef preprocessing directive. Any other predefined macro names shall begin with a leading underscore followed by an uppercase letter or a second underscore.

¶5 The implementation shall not predefine the macro __cplusplus, nor shall it define it in any standard header.

Section 6.10.8 and its sub-sections are similar in ISO/IEC 9899:2011, but the set of macros discussed is more extensive.