Die hier archivierte Mail kann, muss sich aber nicht auf den Themenkomplex von Oekonux beziehen.

Insbesondere kann nicht geschlossen werden, dass die hier geäußerten Inhalte etwas mit dem Projekt Oekonux oder irgendeiner TeilnehmerIn zu tun haben.


Message 01765 [Homepage] [Navigation]
Thread: choxT01763 Message: 2/3 L1 [In date index] [In thread index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Re: [chox] GCC vs. C-Standard


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:

           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

           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.

           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

               ISO C90 (same as -ansi).

               ISO C90 as modified in amendment 1.

               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.

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

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

               The 1998 ISO C++ standard plus amendments.

               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


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

[English translation]
Thread: choxT01763 Message: 2/3 L1 [In date index] [In thread index]
Message 01765 [Homepage] [Navigation]