Re: [chox] GCC vs. C-Standard

• From: Stefan Merten <smerten oekonux.de>
• Date: Tue, 27 Jun 2006 18:22:58 +0200

Hi!

Yesterday Holger Weiss wrote:

| The two editions of the C standard provide almost 100% of the details
| needed to implement a conforming processor of C programs. In contrast
| gcc and other compilers typically document their extensions from the
| users' side ("this is how you can use our new cool feature"), and rarely
| provide enough details for developing a fully compatible implementation.

What about the source code?

| Thus we have open source software limiting interoperability by embracing
| and extending existing standards. [...]
|
| It would be great if we, implementers of open source software, showed
| some temperance in our work and implemented the whole standard and
| (almost) nothing outside the standard. Only then can we honestly claim
| to be really supporting open standards and interoperability.

[ http://www.spinellis.gr/blog/20060625/ ]

Well, seems like someone doesn't know well what s/he speaks of. From
`man gcc`:

       Options Controlling C Dialect

       The following options control the dialect of C (or lan­
       guages derived from C, such as C++ and Objective-C) that
       the compiler accepts:

       -ansi
           In C mode, support all ISO C90 programs.  In C++ mode,
           remove GNU extensions that conflict with ISO C++.

           This turns off certain features of GCC that are incom­
           patible with ISO C90 (when compiling C code), or of
           standard C++ (when compiling C++ code), such as the
           "asm" and "typeof" keywords, and predefined macros
           such as "unix" and "vax" that identify the type of
           system you are using.  It also enables the undesirable
           and rarely used ISO trigraph feature.  For the C com­
           piler, it disables recognition of C++ style // com­
           ments as well as the "inline" keyword.

           The alternate keywords "__asm__", "__extension__",
           "__inline__" and "__typeof__" continue to work despite
           -ansi.  You would not want to use them in an ISO C
           program, of course, but it is useful to put them in
           header files that might be included in compilations
           done with -ansi.  Alternate predefined macros such as
           "__unix__" and "__vax__" are also available, with or
           without -ansi.

           The -ansi option does not cause non-ISO programs to be
           rejected gratuitously.  For that, -pedantic is
           required in addition to -ansi.

           The macro "__STRICT_ANSI__" is predefined when the
           -ansi option is used.  Some header files may notice
           this macro and refrain from declaring certain func­
           tions or defining certain macros that the ISO standard
           doesn't call for; this is to avoid interfering with
           any programs that might use these names for other
           things.

           Functions which would normally be built in but do not
           have semantics defined by ISO C (such as "alloca" and
           "ffs") are not built-in functions with -ansi is used.

       -std=
           Determine the language standard.  This option is cur­
           rently only supported when compiling C or C++.  A
           value for this option must be provided; possible val­
           ues are

           c89
           iso9899:1990
               ISO C90 (same as -ansi).

           iso9899:199409
               ISO C90 as modified in amendment 1.

           c99
           c9x
           iso9899:1999
           iso9899:199x
               ISO C99.  Note that this standard is not yet fully
               supported; see <http://gcc.gnu.org/gcc-3.3/c99sta­;
               tus.html> for more information.  The names c9x and
               iso9899:199x are deprecated.

           gnu89
               Default, ISO C90 plus GNU extensions (including
               some C99 features).

           gnu99
           gnu9x
               ISO C99 plus GNU extensions.  When ISO C99 is
               fully implemented in GCC, this will become the
               default.  The name gnu9x is deprecated.

           c++98
               The 1998 ISO C++ standard plus amendments.

           gnu++98
               The same as -std=c++98 plus GNU extensions.  This
               is the default for C++ code.

           Even when this option is not specified, you can still
           use some of the features of newer standards in so far
           as they do not conflict with previous C standards.
           For example, you may use "__restrict__" even when
           -std=c99 is not specified.

           The -std options specifying some version of ISO C have
           the same effects as -ansi, except that features that
           were not in ISO C90 but are in the specified version
           (for example, // comments and the "inline" keyword in
           ISO C99) are not disabled.

Frankly this looks to me quite differently. It gives the user full
control whether s/he want to allow extensions or not. I wonder whether
there are such switches for instance in the Java implementation of M$.


						Mit Freien Grüßen

						Stefan

--
Please note this message is written on an offline laptop
and send out in the evening of the day it is written. It
does not take any information into account which may have
reached my mailbox since yesterday evening.

_______________________
Web-Site: http://www.oekonux.de/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de

• Follow-Ups:
  • Re: [chox] GCC vs. C-Standard
    • From: Holger Weiss

• References:
  • [chox] GCC vs. C-Standard
    • From: Holger Weiss

• Next in thread: Re: [chox] GCC vs. C-Standard
• Previous in thread: [chox] GCC vs. C-Standard
• First in thread: [chox] GCC vs. C-Standard
• Last in thread: Re: [chox] GCC vs. C-Standard
• Previous thread: [chox] Re: NewCraft - Christine Ax
• Next thread: [chox] Fwd: Kommune-Info-Tour 2006
• Next by Date: [chox] Wikipedia: BGE
• Prev by Date: [chox] Fwd: Kommune-Info-Tour 2006