Re: Why is gcc going to default to "GNU dialect of ISO C99?"

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dennis Clarke]

> BUT: WHATEVER! I was trying to tell you a funny story, nothing more.
> Don't waste your time trying to find there some fundamental statements
> or something.

ok. I owe you three beer.[1]

-- 
Dennis

[1] what good is just one? ;-)

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Patrick Horgan]

Alexey Salmin wrote:
> It all reminds me a story when I won a bottle of beer from my
> scientific adviser back in 2005. We had a bet: will gcc compile this
> code:
> #include <stdio.h>
>  int main() {
>   printf("a");
>   int a;
>   printf("b");
>   return 0;
> }
> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
> I think gnu extensions by default are not so bad :)
>   
if you use -pedantic it will at least whine about it.

Patrick

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[John (Eljay) Love-Jensen]

Hi Alexey,

I stand corrected.  :-)

Sincerely,
--Eljay

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alexey Salmin]

On Thu, Feb 11, 2010 at 8:43 PM, John (Eljay) Love-Jensen
<eljay@adobe.com> wrote:
> Hi Alexey,
>
>> It's not ANSI C compliant.
>
> It's ISO C 1999 compliant.
>
>> And since GNU89 is default for C code...
>
> GNU99 is default of C code, with my GCC (4.0).
>
> I am not sure which GCC version switched from GNU89 to GNU99.
>
> I would expect a GCC of 2005 vintage (e.g., GCC 4.0) to compile C99 code.
>
> Sincerely,
> --Eljay
>

If you read the mail in the beginning of this thread you'll see that
http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
says:
`gnu89'
    GNU dialect of ISO C90 (including some C99 features). (!) This is
the default for C code. (!)
`gnu99'
`gnu9x'
    GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
this (!) will become the default (!). The name `gnu9x' is deprecated.

Same info is in my gcc doc (4.4.2, from Debain Sid)

BUT: WHATEVER! I was trying to tell you a funny story, nothing more.
Don't waste your time trying to find there some fundamental statements
or something.

Alexey

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dennis Clarke]

> On Thu, Feb 11, 2010 at 8:00 PM, Dennis Clarke <dclarke@blastwave.org>
> wrote:
>>
>>> On Thu, Feb 11, 2010 at 7:40 PM, Dennis Clarke <dclarke@blastwave.org>
>>> wrote:
>>>>
>>>>> It all reminds me a story when I won a bottle of beer from my
>>>>> scientific adviser back in 2005. We had a bet: will gcc compile this
>>>>> code:
>>>>> #include <stdio.h>
>>>>>  int main() {
>>>>>   printf("a");
>>>>>   int a;
>>>>>   printf("b");
>>>>>   return 0;
>>>>> }
>>>>> He was so sure that gcc won't allow it that didn't ever tried :)
>>>>> Thus,
>>>>> I think gnu extensions by default are not so bad :)
>>>>>
>>>>> Alexey
>>>>
>>>> Let's have a look at that. I don't see any issues really. You call
>>>> printf() with a literal string, then define some simple integer, then
>>>> print another literal string with a call to printf() and finally
>>>> return
>>>> back to the calling process with a status of 0. Very nice.
>>>>
>> <snip>
>>>
>>> 334 lines of research for 7 lines of code :)
>>>
>>> Alexey
>>
>> Here are 7 more :-)
>>
>> $ lint -v -Nlevel=4 -Xc99=all sample1.c
>>
>> variable unused in function
>>    (9) a in main
>>
>> function returns value which is always ignored
>>    printf
>>
>>
>> --
>> Dennis Clarke
>> dclarke@opensolaris.ca  <- Email related to the open source Solaris
>> dclarke@blastwave.org   <- Email related to open source for Solaris
>>
>>
>>
>
> What for? If you read my messages carefully you'll understand that I
> know it works with gcc perfectly. Actually I've won a bottle of beer
> due to that knowledge :)
> But try to compile that code with MSVS for instance (or try reading
> C89 standard) and you'll see why it was possible that it would NOT
> work.
>
> Alexey

               point missing, you are

While you, as an intelligent human, may be able to understand those four
words and one punctuation mark you must agree that it is badly formed
english. In fact, it is horribly wrong from the perspective of grammer and
syntax.

The fact that some compiler somewhere may be able to compile some badly
formed code does not mean that the compiler is good. It does not even mean
that what the compiler is doing is correct.

A programming language, unlike a spoken or written language, must be
precise in its syntax and grammer in the same way that mathematics is a
precise language. A person may be able to interpret poorly formed spoken
or written language but a computer programming language should be portable
and correctly formed. Again, I may be wasting my efforts here because the
GCC developers may have left such ideals long behind them.

-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alexey Salmin]

On Thu, Feb 11, 2010 at 8:00 PM, Dennis Clarke <dclarke@blastwave.org> wrote:
>
>> On Thu, Feb 11, 2010 at 7:40 PM, Dennis Clarke <dclarke@blastwave.org>
>> wrote:
>>>
>>>> It all reminds me a story when I won a bottle of beer from my
>>>> scientific adviser back in 2005. We had a bet: will gcc compile this
>>>> code:
>>>> #include <stdio.h>
>>>>  int main() {
>>>>   printf("a");
>>>>   int a;
>>>>   printf("b");
>>>>   return 0;
>>>> }
>>>> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
>>>> I think gnu extensions by default are not so bad :)
>>>>
>>>> Alexey
>>>
>>> Let's have a look at that. I don't see any issues really. You call
>>> printf() with a literal string, then define some simple integer, then
>>> print another literal string with a call to printf() and finally return
>>> back to the calling process with a status of 0. Very nice.
>>>
> <snip>
>>
>> 334 lines of research for 7 lines of code :)
>>
>> Alexey
>
> Here are 7 more :-)
>
> $ lint -v -Nlevel=4 -Xc99=all sample1.c
>
> variable unused in function
>    (9) a in main
>
> function returns value which is always ignored
>    printf
>
>
> --
> Dennis Clarke
> dclarke@opensolaris.ca  <- Email related to the open source Solaris
> dclarke@blastwave.org   <- Email related to open source for Solaris
>
>
>

What for? If you read my messages carefully you'll understand that I
know it works with gcc perfectly. Actually I've won a bottle of beer
due to that knowledge :)
But try to compile that code with MSVS for instance (or try reading
C89 standard) and you'll see why it was possible that it would NOT
work.

Alexey

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dennis Clarke]

> On Thu, Feb 11, 2010 at 7:40 PM, Dennis Clarke <dclarke@blastwave.org>
> wrote:
>>
>>> It all reminds me a story when I won a bottle of beer from my
>>> scientific adviser back in 2005. We had a bet: will gcc compile this
>>> code:
>>> #include <stdio.h>
>>>  int main() {
>>>   printf("a");
>>>   int a;
>>>   printf("b");
>>>   return 0;
>>> }
>>> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
>>> I think gnu extensions by default are not so bad :)
>>>
>>> Alexey
>>
>> Let's have a look at that. I don't see any issues really. You call
>> printf() with a literal string, then define some simple integer, then
>> print another literal string with a call to printf() and finally return
>> back to the calling process with a status of 0. Very nice.
>>
<snip>
>
> 334 lines of research for 7 lines of code :)
>
> Alexey

Here are 7 more :-)

$ lint -v -Nlevel=4 -Xc99=all sample1.c

variable unused in function
    (9) a in main

function returns value which is always ignored
    printf


-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alexey Salmin]

On Thu, Feb 11, 2010 at 7:40 PM, Dennis Clarke <dclarke@blastwave.org> wrote:
>
>> It all reminds me a story when I won a bottle of beer from my
>> scientific adviser back in 2005. We had a bet: will gcc compile this
>> code:
>> #include <stdio.h>
>>  int main() {
>>   printf("a");
>>   int a;
>>   printf("b");
>>   return 0;
>> }
>> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
>> I think gnu extensions by default are not so bad :)
>>
>> Alexey
>
> Let's have a look at that. I don't see any issues really. You call
> printf() with a literal string, then define some simple integer, then
> print another literal string with a call to printf() and finally return
> back to the calling process with a status of 0. Very nice.
>
> $ date
> Thu Feb 11 13:28:17 GMT 2010
> $ uname -a
> SunOS aequitas 5.11 snv_130 i86pc i386 i86pc
> $
> $ cat /etc/release
>                  Solaris Express Community Edition snv_130 X86
>           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
>                        Use is subject to license terms.
>                           Assembled 14 December 2009
> $
> $ /opt/csw/gcc4/bin/gcc --version
> gcc (GCC) 4.3.4
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> $ ls
> sample1.c
> $
> $ cat -n sample1.c
>     1  /********************************************************************
>     2   From "Alexey Salmin" <alexey.salmin@gmail.com> email message
>     3   posted to gcc-help@gcc.gnu.org Thu, February 11, 2010 04:43
>     4   Subject Re: Why is gcc going to default to "GNU dialect of ISO C99?"
>     5
> *********************************************************************/
>     6  #include <stdio.h>
>     7   int main() {
>     8    printf("a");
>     9    int a;
>    10    printf("b");
>    11    return 0;
>    12  }
> $
>
> $ /opt/csw/gcc4/bin/gcc -v -std=iso9899:1990 -c -o sample1.o sample1.c
> Using built-in specs.
> Target: i386-pc-solaris2.10
> Configured with: /export/medusa/dclarke/build/GCC/gcc-4.3.4/configure
> --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas
> --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386
> --with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron
> --enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/opt/csw
> --enable-threads=posix --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw
> --enable-shared --enable-multilib --with-included-gettext
> --with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
> --enable-languages=c,c++,objc,fortran --enable-bootstrap
> Thread model: posix
> gcc version 4.3.4 (GCC)
> COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
> '-mtune=generic'
>  /opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/cc1 -quiet -v
> sample1.c -quiet -dumpbase sample1.c -mtune=generic -auxbase-strip
> sample1.o -std=iso9899:1990 -version -o /var/tmp//ccGRlbZX.s
> ignoring nonexistent directory
> "/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../../i386-pc-solaris2.10/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  /opt/csw/include
>  /opt/csw/gcc4/include
>  /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/include
>  /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/include-fixed
>  /usr/include
> End of search list.
> GNU C (GCC) version 4.3.4 (i386-pc-solaris2.10)
>        compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version
> 2.4.2-rc1.
> warning: MPFR header version 2.4.2-rc1 differs from library version 2.4.2.
> GGC heuristics: --param ggc-min-expand=95 --param ggc-min-heapsize=122687
> Compiler executable checksum: 9ba7f205b9cefa6eae48c8f511c89b44
> COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
> '-mtune=generic'
>  /opt/csw/bin/gas -v -V -Qy -s -o sample1.o /var/tmp//ccGRlbZX.s
> GNU assembler version 2.19.1 (i386-pc-solaris2.8) using BFD version (GNU
> Binutils) 2.19.1
> COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
> LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
> '-mtune=generic'
> $
> $ ls -lap
> total 8
> drwxr-xr-x   2 dclarke  csw          512 Feb 11 13:29 ./
> drwxr-xr-x   3 dclarke  csw          512 Feb 11 13:23 ../
> -rw-r--r--   1 dclarke  csw          420 Feb 11 13:28 sample1.c
> -rw-r--r--   1 dclarke  csw          712 Feb 11 13:29 sample1.o
> $ /opt/csw/gcc4/bin/gcc -v -std=iso9899:1990 -o sample1 sample1.o
> Using built-in specs.
> Target: i386-pc-solaris2.10
> Configured with: /export/medusa/dclarke/build/GCC/gcc-4.3.4/configure
> --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas
> --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386
> --with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron
> --enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/opt/csw
> --enable-threads=posix --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw
> --enable-shared --enable-multilib --with-included-gettext
> --with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
> --enable-languages=c,c++,objc,fortran --enable-bootstrap
> Thread model: posix
> gcc version 4.3.4 (GCC)
> COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
> LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../:/lib/:/usr/lib/
> COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-o' 'sample1' '-mtune=generic'
>  /opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/collect2 -V -Y
> P,/usr/ccs/lib:/usr/lib -Qy -o sample1 /usr/lib/crt1.o /usr/lib/crti.o
> /usr/lib/values-Xa.o
> /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/crtbegin.o
> -L/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4
> -L/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../.. sample1.o
> -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
> /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/crtend.o /usr/lib/crtn.o
> ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1688
> $
> $ ls -lap
> total 24
> drwxr-xr-x   2 dclarke  csw          512 Feb 11 13:30 ./
> drwxr-xr-x   3 dclarke  csw          512 Feb 11 13:23 ../
> -rwxr-xr-x   1 dclarke  csw         8096 Feb 11 13:30 sample1
> -rw-r--r--   1 dclarke  csw          420 Feb 11 13:28 sample1.c
> -rw-r--r--   1 dclarke  csw          712 Feb 11 13:29 sample1.o
> $
> $ elfdump -d sample1
>
> Dynamic Section:  .dynamic
>     index  tag                value
>       [0]  NEEDED            0x1e8               libc.so.1
>       [1]  INIT              0x8050d20
>       [2]  FINI              0x8050d40
>       [3]  HASH              0x8050144
>       [4]  STRTAB            0x80504f4
>       [5]  STRSZ             0x40e
>       [6]  SYMTAB            0x8050304
>       [7]  SYMENT            0x10
>       [8]  SUNW_SYMTAB       0x8050244
>       [9]  SUNW_SYMSZ        0x2b0
>      [10]  SUNW_SORTENT      0x4
>      [11]  SUNW_SYMSORT      0x8050974
>      [12]  SUNW_SYMSORTSZ    0x3c
>      [13]  CHECKSUM          0x6176
>      [14]  VERNEED           0x8050904
>      [15]  VERNEEDNUM        0x1
>      [16]  PLTRELSZ          0x40
>      [17]  PLTREL            0x11
>      [18]  JMPREL            0x80509d8
>      [19]  REL               0x80509b0
>      [20]  RELSZ             0x68
>      [21]  RELENT            0x8
>      [22]  DEBUG             0
>      [23]  FEATURE_1         0x1                 [ PARINIT ]
>      [24]  SUNW_CAP          0x8050128
>      [25]  FLAGS             0                   0
>      [26]  FLAGS_1           0                   0
>      [27]  SUNW_STRPAD       0x200
>      [28]  SUNW_LDMACH       0x3                 EM_386
>      [29]  PLTGOT            0x8060d5c
>   [30-40]  NULL              0
> $
> $ ./sample1
> ab$
> $
> $ ./sample1 | od -Ax -t x1
> 0000000 61 62
> 0000002
> $
>
> No problem there at all.
>
> Let's try the same thing with Sun Studio 12 on Solaris 10 :
>
> $ uname -a
> SunOS vanth 5.10 Generic_142901-03 i86pc i386 i86pc
> $ cat /etc/release
>                        Solaris 10 5/09 s10x_u7wos_08 X86
>           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
>                        Use is subject to license terms.
>                             Assembled 30 March 2009
> $
> $ which cc
> /opt/studio/SOS12/SUNWspro/bin/cc
> $
> $ cc -V
> cc: Sun C 5.9 SunOS_i386 Patch 124868-11 2009/11/21
> usage: cc [ options] files.  Use 'cc -flags' for details
> $
> $ ls
> sample1.c
> $
> $ cc -\# -H -Qy -Xc -xbuiltin=%none -Kpic -xildoff -xregs=no%frameptr -xs
> -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE -c -o sample1.o sample1.c
> ### Note: NLSPATH =
> /opt/studio/SOS12/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/studio/SOS12/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
> ###     command line files and options (expanded):
> ### -c -D_TS_ERRNO -D_POSIX_SOURCE -g -H -Kpic -Xc -features=no%typeof
> -xregs=no%frameptr -xs -xstrconst sample1.c -o sample1.o
> /opt/studio/SOS12/SUNWspro/prod/bin/acomp -dg -xldscope=global -i
> sample1.c -y-fbe -y/opt/studio/SOS12/SUNWspro/prod/bin/fbe -y-pic
> -y-xarch=generic -y-g -y-o -ysample1.o -y-verbose -y-xthreadvar=dynamic
> -y-comdat -xdbggen=no%stabs+dwarf2+usedonly -H -strconst -D_TS_ERRNO
> -D_POSIX_SOURCE -xdbggen=incl -y-s -2k -m32 -fparam_ir -Qy -D__SunOS_5_10
> -D__SUNPRO_C=0x590 -D__SVR4 -D__sun -D__SunOS -D__unix -D__i386
> -D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -Xc -D__PRAGMA_REDEFINE_EXTNAME
> -xc99=%all,no%lib -D__FLT_EVAL_METHOD__=-1 -features=no%typeof
> -I/opt/studio/SOS12/SUNWspro/prod/include/cc
> "-g/opt/studio/SOS12/SUNWspro/prod/bin/cc -H -Qy -Xc -xbuiltin=%none -Kpic
> -xildoff -xregs=no%frameptr -xs -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE
> -c -o sample1.o " -fsimple=0 -D__SUN_PREFETCH -destination_ir=yabe
> /usr/include/stdio.h
>        /usr/include/sys/feature_tests.h
>                /usr/include/sys/ccompile.h
>                /usr/include/sys/isa_defs.h
>        /usr/include/iso/stdio_iso.h
>                /usr/include/sys/va_list.h
>                /usr/include/stdio_tag.h
>                /usr/include/stdio_impl.h
>        /usr/include/iso/stdio_c99.h
> /opt/studio/SOS12/SUNWspro/prod/bin/fbe -s -o sample1.o -warn=%none -Qy
> /tmp/yabeAAARnaqit
> rm /tmp/yabeAAARnaqit
> $
> $ ls -l
> total 3
> -rw-r--r--   1 dclarke  csw          420 Feb 11 13:35 sample1.c
> -rw-r--r--   1 dclarke  csw         3888 Feb 11 13:37 sample1.o
> $
> $ cc -\# -H -Qy -Xc -xbuiltin=%none -Kpic -xildoff -xregs=no%frameptr -xs
> -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE -o sample1 sample1.c
> ### Note: NLSPATH =
> /opt/studio/SOS12/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/studio/SOS12/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
> ###     command line files and options (expanded):
> ### -D_TS_ERRNO -D_POSIX_SOURCE -g -H -Kpic -Xc -features=no%typeof
> -xregs=no%frameptr -xs -xstrconst sample1.c -o sample1
> /opt/studio/SOS12/SUNWspro/prod/bin/acomp -dg -xldscope=global -i
> sample1.c -y-fbe -y/opt/studio/SOS12/SUNWspro/prod/bin/fbe -y-pic
> -y-xarch=generic -y-g -y-o -ysample1.o -y-verbose -y-xthreadvar=dynamic
> -y-comdat -xdbggen=no%stabs+dwarf2+usedonly -H -strconst -D_TS_ERRNO
> -D_POSIX_SOURCE -xdbggen=incl -y-s -2k -m32 -fparam_ir -Qy -D__SunOS_5_10
> -D__SUNPRO_C=0x590 -D__SVR4 -D__sun -D__SunOS -D__unix -D__i386
> -D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -Xc -D__PRAGMA_REDEFINE_EXTNAME
> -xc99=%all,no%lib -D__FLT_EVAL_METHOD__=-1 -features=no%typeof
> -I/opt/studio/SOS12/SUNWspro/prod/include/cc
> "-g/opt/studio/SOS12/SUNWspro/prod/bin/cc -H -Qy -Xc -xbuiltin=%none -Kpic
> -xildoff -xregs=no%frameptr -xs -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE
> -c " -fsimple=0 -D__SUN_PREFETCH -destination_ir=yabe
> /usr/include/stdio.h
>        /usr/include/sys/feature_tests.h
>                /usr/include/sys/ccompile.h
>                /usr/include/sys/isa_defs.h
>        /usr/include/iso/stdio_iso.h
>                /usr/include/sys/va_list.h
>                /usr/include/stdio_tag.h
>                /usr/include/stdio_impl.h
>        /usr/include/iso/stdio_c99.h
> /opt/studio/SOS12/SUNWspro/prod/bin/fbe -s -o sample1.o -warn=%none -Qy
> /tmp/yabeAAA_BaWit
> rm /tmp/yabeAAA_BaWit
> ### Note: LD_LIBRARY_PATH = <null>
> ### Note: LD_RUN_PATH = <null>
> /usr/ccs/bin/ld /opt/studio/SOS12/SUNWspro/prod/lib/crti.o
> /opt/studio/SOS12/SUNWspro/prod/lib/crt1.o
> /opt/studio/SOS12/SUNWspro/prod/lib/values-xc.o -o sample1 sample1.o -Y
> "P,/opt/studio/SOS12/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib" -Qy -lc
> /opt/studio/SOS12/SUNWspro/prod/lib/crtn.o
> $
> $ ls -l
> total 3
> -rwxr-xr-x   1 dclarke  csw         7520 Feb 11 13:37 sample1
> -rw-r--r--   1 dclarke  csw          420 Feb 11 13:35 sample1.c
> $
> $ file sample1
> sample1: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
> linked, not stripped
> $
> $ elfdump -d sample1
>
> Dynamic Section:  .dynamic
>     index  tag                value
>       [0]  NEEDED            0x114               libc.so.1
>       [1]  INIT              0x8050738
>       [2]  FINI              0x8050754
>       [3]  RUNPATH           0x13a               /opt/csw/lib/amd64
>       [4]  RPATH             0x13a               /opt/csw/lib/amd64
>       [5]  HASH              0x8050118
>       [6]  STRTAB            0x805039c
>       [7]  STRSZ             0x14d
>       [8]  SYMTAB            0x80501fc
>       [9]  SYMENT            0x10
>      [10]  CHECKSUM          0x7ef0
>      [11]  VERNEED           0x80504ec
>      [12]  VERNEEDNUM        0x1
>      [13]  PLTRELSZ          0x30
>      [14]  PLTREL            0x11
>      [15]  JMPREL            0x8050524
>      [16]  REL               0x805051c
>      [17]  RELSZ             0x38
>      [18]  RELENT            0x8
>      [19]  DEBUG             0
>      [20]  FEATURE_1         0x1                 [ PARINIT ]
>      [21]  SUNW_CAP          0x8050108
>      [22]  FLAGS             0                   0
>      [23]  FLAGS_1           0                   0
>      [24]  PLTGOT            0x806077c
>      [25]  NULL              0
> $
> $ ./sample1
> ab$
> $
> $ ./sample1 | od -Ax -t x1
> 0000000 61 62
> 0000002
> $
>
> No problems there either.
>
> --
> Dennis Clarke
> dclarke@opensolaris.ca  <- Email related to the open source Solaris
> dclarke@blastwave.org   <- Email related to open source for Solaris
>
>

334 lines of research for 7 lines of code :)

Alexey

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alexey Salmin]

On Thu, Feb 11, 2010 at 6:23 PM, John (Eljay) Love-Jensen
<eljay@adobe.com> wrote:
> Hi Alexey,
>
>> It all reminds me a story when I won a bottle of beer from my
>> scientific adviser back in 2005. We had a bet: will gcc compile this
>> code:
>> #include <stdio.h>
>>  int main() {
>>   printf("a");
>>   int a;
>>   printf("b");
>>   return 0;
>> }
>> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
>> I think gnu extensions by default are not so bad :)
>
> Why wouldn't GCC compile that code?
>
> It is ISO 9899:1999 compliant.  Even compiles with the -pedantic flag.  (Or
> am I missing something?)
>
> Mmmmmm, beer.  :-)
>
> Sincerely,
> --Eljay
>

It's not ANSI C compliant. And since GNU89 is default for C code it's
reasonable (in some way) for this not to work.
Fortunately I wasn't very familiar with different standarts and stuff
that time, I just knew that it works with GCC :)

This code actually gives a warning with -pedantic and error (your C.O.
:P ) with -pedantic-errors.

salmin@salmin:~/test$ gcc -o test test.c
salmin@salmin:~/test$ gcc -std=gnu89 -o test test.c
salmin@salmin:~/test$ gcc -std=c89 -o test test.c
salmin@salmin:~/test$ gcc -pedantic -o test test.c
test.c: In function ‘main’:
test.c:5: warning: ISO C90 forbids mixed declarations and code

salmin@salmin:~/test$ gcc -pedantic-errors -o test test.c
test.c: In function ‘main’:
test.c:5: error: ISO C90 forbids mixed declarations and code

salmin@salmin:~/test$ gcc -std=c89 -pedantic-errors -o test test.c
test.c: In function ‘main’:
test.c:5: error: ISO C90 forbids mixed declarations and code

salmin@salmin:~/test$ gcc -std=gnu89 -pedantic-errors -o test test.c
test.c: In function ‘main’:
test.c:5: error: ISO C90 forbids mixed declarations and code

salmin@salmin:~/test$ gcc -std=c99 -pedantic-errors -o test test.c

salmin@salmin:~/test$ gcc -std=gnu99 -pedantic-errors -o test test.c

salmin@salmin:~/test$ cat test.c
#include <stdio.h>

int main() {
        printf("a");
        int a;
        printf("b");
        return 0;
}

Alexey

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dennis Clarke]

> It all reminds me a story when I won a bottle of beer from my
> scientific adviser back in 2005. We had a bet: will gcc compile this
> code:
> #include <stdio.h>
>  int main() {
>   printf("a");
>   int a;
>   printf("b");
>   return 0;
> }
> He was so sure that gcc won't allow it that didn't ever tried :) Thus,
> I think gnu extensions by default are not so bad :)
>
> Alexey

Let's have a look at that. I don't see any issues really. You call
printf() with a literal string, then define some simple integer, then
print another literal string with a call to printf() and finally return
back to the calling process with a status of 0. Very nice.

$ date
Thu Feb 11 13:28:17 GMT 2010
$ uname -a
SunOS aequitas 5.11 snv_130 i86pc i386 i86pc
$
$ cat /etc/release
                  Solaris Express Community Edition snv_130 X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 14 December 2009
$
$ /opt/csw/gcc4/bin/gcc --version
gcc (GCC) 4.3.4
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ ls
sample1.c
$
$ cat -n sample1.c
     1  /********************************************************************
     2   From "Alexey Salmin" <alexey.salmin@gmail.com> email message
     3   posted to gcc-help@gcc.gnu.org Thu, February 11, 2010 04:43
     4   Subject Re: Why is gcc going to default to "GNU dialect of ISO C99?"
     5 
*********************************************************************/
     6  #include <stdio.h>
     7   int main() {
     8    printf("a");
     9    int a;
    10    printf("b");
    11    return 0;
    12  }
$

$ /opt/csw/gcc4/bin/gcc -v -std=iso9899:1990 -c -o sample1.o sample1.c
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/medusa/dclarke/build/GCC/gcc-4.3.4/configure
--build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386
--with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron
--enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/opt/csw
--enable-threads=posix --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw
--enable-shared --enable-multilib --with-included-gettext
--with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
--enable-languages=c,c++,objc,fortran --enable-bootstrap
Thread model: posix
gcc version 4.3.4 (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
'-mtune=generic'
 /opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/cc1 -quiet -v
sample1.c -quiet -dumpbase sample1.c -mtune=generic -auxbase-strip
sample1.o -std=iso9899:1990 -version -o /var/tmp//ccGRlbZX.s
ignoring nonexistent directory
"/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../../i386-pc-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/csw/include
 /opt/csw/gcc4/include
 /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/include
 /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/include-fixed
 /usr/include
End of search list.
GNU C (GCC) version 4.3.4 (i386-pc-solaris2.10)
        compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version
2.4.2-rc1.
warning: MPFR header version 2.4.2-rc1 differs from library version 2.4.2.
GGC heuristics: --param ggc-min-expand=95 --param ggc-min-heapsize=122687
Compiler executable checksum: 9ba7f205b9cefa6eae48c8f511c89b44
COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
'-mtune=generic'
 /opt/csw/bin/gas -v -V -Qy -s -o sample1.o /var/tmp//ccGRlbZX.s
GNU assembler version 2.19.1 (i386-pc-solaris2.8) using BFD version (GNU
Binutils) 2.19.1
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-c' '-o' 'sample1.o'
'-mtune=generic'
$
$ ls -lap
total 8
drwxr-xr-x   2 dclarke  csw          512 Feb 11 13:29 ./
drwxr-xr-x   3 dclarke  csw          512 Feb 11 13:23 ../
-rw-r--r--   1 dclarke  csw          420 Feb 11 13:28 sample1.c
-rw-r--r--   1 dclarke  csw          712 Feb 11 13:29 sample1.o
$ /opt/csw/gcc4/bin/gcc -v -std=iso9899:1990 -o sample1 sample1.o
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/medusa/dclarke/build/GCC/gcc-4.3.4/configure
--build=i386-pc-solaris2.10 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-cpu-32=i386
--with-cpu-64=opteron --with-arch-32=i386 --with-arch-64=opteron
--enable-stage1-languages=c --enable-nls --with-libiconv-prefix=/opt/csw
--enable-threads=posix --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw
--enable-shared --enable-multilib --with-included-gettext
--with-system-zlib --with-gmp=/opt/csw --with-mpfr=/opt/csw
--enable-languages=c,c++,objc,fortran --enable-bootstrap
Thread model: posix
gcc version 4.3.4 (GCC)
COMPILER_PATH=/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/:/usr/ccs/bin/
LIBRARY_PATH=/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/:/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=iso9899:1990' '-o' 'sample1' '-mtune=generic'
 /opt/csw/gcc4/libexec/gcc/i386-pc-solaris2.10/4.3.4/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -Qy -o sample1 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/values-Xa.o
/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/crtbegin.o
-L/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4
-L/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/../../.. sample1.o
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.10/4.3.4/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1688
$
$ ls -lap
total 24
drwxr-xr-x   2 dclarke  csw          512 Feb 11 13:30 ./
drwxr-xr-x   3 dclarke  csw          512 Feb 11 13:23 ../
-rwxr-xr-x   1 dclarke  csw         8096 Feb 11 13:30 sample1
-rw-r--r--   1 dclarke  csw          420 Feb 11 13:28 sample1.c
-rw-r--r--   1 dclarke  csw          712 Feb 11 13:29 sample1.o
$
$ elfdump -d sample1

Dynamic Section:  .dynamic
     index  tag                value
       [0]  NEEDED            0x1e8               libc.so.1
       [1]  INIT              0x8050d20
       [2]  FINI              0x8050d40
       [3]  HASH              0x8050144
       [4]  STRTAB            0x80504f4
       [5]  STRSZ             0x40e
       [6]  SYMTAB            0x8050304
       [7]  SYMENT            0x10
       [8]  SUNW_SYMTAB       0x8050244
       [9]  SUNW_SYMSZ        0x2b0
      [10]  SUNW_SORTENT      0x4
      [11]  SUNW_SYMSORT      0x8050974
      [12]  SUNW_SYMSORTSZ    0x3c
      [13]  CHECKSUM          0x6176
      [14]  VERNEED           0x8050904
      [15]  VERNEEDNUM        0x1
      [16]  PLTRELSZ          0x40
      [17]  PLTREL            0x11
      [18]  JMPREL            0x80509d8
      [19]  REL               0x80509b0
      [20]  RELSZ             0x68
      [21]  RELENT            0x8
      [22]  DEBUG             0
      [23]  FEATURE_1         0x1                 [ PARINIT ]
      [24]  SUNW_CAP          0x8050128
      [25]  FLAGS             0                   0
      [26]  FLAGS_1           0                   0
      [27]  SUNW_STRPAD       0x200
      [28]  SUNW_LDMACH       0x3                 EM_386
      [29]  PLTGOT            0x8060d5c
   [30-40]  NULL              0
$
$ ./sample1
ab$
$
$ ./sample1 | od -Ax -t x1
0000000 61 62
0000002
$

No problem there at all.

Let's try the same thing with Sun Studio 12 on Solaris 10 :

$ uname -a
SunOS vanth 5.10 Generic_142901-03 i86pc i386 i86pc
$ cat /etc/release
                        Solaris 10 5/09 s10x_u7wos_08 X86
           Copyright 2009 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 30 March 2009
$
$ which cc
/opt/studio/SOS12/SUNWspro/bin/cc
$
$ cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-11 2009/11/21
usage: cc [ options] files.  Use 'cc -flags' for details
$
$ ls
sample1.c
$
$ cc -\# -H -Qy -Xc -xbuiltin=%none -Kpic -xildoff -xregs=no%frameptr -xs
-xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE -c -o sample1.o sample1.c
### Note: NLSPATH =
/opt/studio/SOS12/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/studio/SOS12/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### -c -D_TS_ERRNO -D_POSIX_SOURCE -g -H -Kpic -Xc -features=no%typeof 
-xregs=no%frameptr -xs -xstrconst sample1.c -o sample1.o
/opt/studio/SOS12/SUNWspro/prod/bin/acomp -dg -xldscope=global -i
sample1.c -y-fbe -y/opt/studio/SOS12/SUNWspro/prod/bin/fbe -y-pic
-y-xarch=generic -y-g -y-o -ysample1.o -y-verbose -y-xthreadvar=dynamic
-y-comdat -xdbggen=no%stabs+dwarf2+usedonly -H -strconst -D_TS_ERRNO
-D_POSIX_SOURCE -xdbggen=incl -y-s -2k -m32 -fparam_ir -Qy -D__SunOS_5_10
-D__SUNPRO_C=0x590 -D__SVR4 -D__sun -D__SunOS -D__unix -D__i386
-D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -Xc -D__PRAGMA_REDEFINE_EXTNAME
-xc99=%all,no%lib -D__FLT_EVAL_METHOD__=-1 -features=no%typeof
-I/opt/studio/SOS12/SUNWspro/prod/include/cc
"-g/opt/studio/SOS12/SUNWspro/prod/bin/cc -H -Qy -Xc -xbuiltin=%none -Kpic
-xildoff -xregs=no%frameptr -xs -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE
-c -o sample1.o " -fsimple=0 -D__SUN_PREFETCH -destination_ir=yabe
/usr/include/stdio.h
        /usr/include/sys/feature_tests.h
                /usr/include/sys/ccompile.h
                /usr/include/sys/isa_defs.h
        /usr/include/iso/stdio_iso.h
                /usr/include/sys/va_list.h
                /usr/include/stdio_tag.h
                /usr/include/stdio_impl.h
        /usr/include/iso/stdio_c99.h
/opt/studio/SOS12/SUNWspro/prod/bin/fbe -s -o sample1.o -warn=%none -Qy
/tmp/yabeAAARnaqit
rm /tmp/yabeAAARnaqit
$
$ ls -l
total 3
-rw-r--r--   1 dclarke  csw          420 Feb 11 13:35 sample1.c
-rw-r--r--   1 dclarke  csw         3888 Feb 11 13:37 sample1.o
$
$ cc -\# -H -Qy -Xc -xbuiltin=%none -Kpic -xildoff -xregs=no%frameptr -xs
-xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE -o sample1 sample1.c
### Note: NLSPATH =
/opt/studio/SOS12/SUNWspro/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/studio/SOS12/SUNWspro/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
###     command line files and options (expanded):
### -D_TS_ERRNO -D_POSIX_SOURCE -g -H -Kpic -Xc -features=no%typeof 
-xregs=no%frameptr -xs -xstrconst sample1.c -o sample1
/opt/studio/SOS12/SUNWspro/prod/bin/acomp -dg -xldscope=global -i
sample1.c -y-fbe -y/opt/studio/SOS12/SUNWspro/prod/bin/fbe -y-pic
-y-xarch=generic -y-g -y-o -ysample1.o -y-verbose -y-xthreadvar=dynamic
-y-comdat -xdbggen=no%stabs+dwarf2+usedonly -H -strconst -D_TS_ERRNO
-D_POSIX_SOURCE -xdbggen=incl -y-s -2k -m32 -fparam_ir -Qy -D__SunOS_5_10
-D__SUNPRO_C=0x590 -D__SVR4 -D__sun -D__SunOS -D__unix -D__i386
-D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -Xc -D__PRAGMA_REDEFINE_EXTNAME
-xc99=%all,no%lib -D__FLT_EVAL_METHOD__=-1 -features=no%typeof
-I/opt/studio/SOS12/SUNWspro/prod/include/cc
"-g/opt/studio/SOS12/SUNWspro/prod/bin/cc -H -Qy -Xc -xbuiltin=%none -Kpic
-xildoff -xregs=no%frameptr -xs -xstrconst -g -D_TS_ERRNO -D_POSIX_SOURCE
-c " -fsimple=0 -D__SUN_PREFETCH -destination_ir=yabe
/usr/include/stdio.h
        /usr/include/sys/feature_tests.h
                /usr/include/sys/ccompile.h
                /usr/include/sys/isa_defs.h
        /usr/include/iso/stdio_iso.h
                /usr/include/sys/va_list.h
                /usr/include/stdio_tag.h
                /usr/include/stdio_impl.h
        /usr/include/iso/stdio_c99.h
/opt/studio/SOS12/SUNWspro/prod/bin/fbe -s -o sample1.o -warn=%none -Qy
/tmp/yabeAAA_BaWit
rm /tmp/yabeAAA_BaWit
### Note: LD_LIBRARY_PATH = <null>
### Note: LD_RUN_PATH = <null>
/usr/ccs/bin/ld /opt/studio/SOS12/SUNWspro/prod/lib/crti.o
/opt/studio/SOS12/SUNWspro/prod/lib/crt1.o
/opt/studio/SOS12/SUNWspro/prod/lib/values-xc.o -o sample1 sample1.o -Y
"P,/opt/studio/SOS12/SUNWspro/prod/lib:/usr/ccs/lib:/lib:/usr/lib" -Qy -lc
/opt/studio/SOS12/SUNWspro/prod/lib/crtn.o
$
$ ls -l
total 3
-rwxr-xr-x   1 dclarke  csw         7520 Feb 11 13:37 sample1
-rw-r--r--   1 dclarke  csw          420 Feb 11 13:35 sample1.c
$
$ file sample1
sample1: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically
linked, not stripped
$
$ elfdump -d sample1

Dynamic Section:  .dynamic
     index  tag                value
       [0]  NEEDED            0x114               libc.so.1
       [1]  INIT              0x8050738
       [2]  FINI              0x8050754
       [3]  RUNPATH           0x13a               /opt/csw/lib/amd64
       [4]  RPATH             0x13a               /opt/csw/lib/amd64
       [5]  HASH              0x8050118
       [6]  STRTAB            0x805039c
       [7]  STRSZ             0x14d
       [8]  SYMTAB            0x80501fc
       [9]  SYMENT            0x10
      [10]  CHECKSUM          0x7ef0
      [11]  VERNEED           0x80504ec
      [12]  VERNEEDNUM        0x1
      [13]  PLTRELSZ          0x30
      [14]  PLTREL            0x11
      [15]  JMPREL            0x8050524
      [16]  REL               0x805051c
      [17]  RELSZ             0x38
      [18]  RELENT            0x8
      [19]  DEBUG             0
      [20]  FEATURE_1         0x1                 [ PARINIT ]
      [21]  SUNW_CAP          0x8050108
      [22]  FLAGS             0                   0
      [23]  FLAGS_1           0                   0
      [24]  PLTGOT            0x806077c
      [25]  NULL              0
$
$ ./sample1
ab$
$
$ ./sample1 | od -Ax -t x1
0000000 61 62
0000002
$

No problems there either.

-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alexey Salmin]

It all reminds me a story when I won a bottle of beer from my
scientific adviser back in 2005. We had a bet: will gcc compile this
code:
#include <stdio.h>
 int main() {
  printf("a");
  int a;
  printf("b");
  return 0;
}
He was so sure that gcc won't allow it that didn't ever tried :) Thus,
I think gnu extensions by default are not so bad :)

Alexey

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alfred M. Szmidt]

If you wish to use a compiler that ad hers to ISO C99, then you should
use the c99 program as per POSIX 1003.1 2004; that is the proper and
standard compliant way to invoke a ISO C99 compiler.  What the gcc
program will do by default is set by the GNU project, the g after all
stands for GNU, not ISO or POSIX.

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Ian Lance Taylor]

"Dr. David Kirkby" <david.kirkby@onetel.net> writes:

> A lot of bugs are often discovered in code by testing on multiple
> compilers and multiple platforms. What one compiler misses, another
> finds. I could point you to various cases where the Sun compiler has
> rejected erroneous code that gcc has permitted. I'm sure you could no
> doubt find counter examples too.
>
> By generating code that should build with other compilers, problems
> can be detected more easily.

You are looking for the -pedantic option, q.v.

It is extremely unlikely that this decision about gcc's default
behaviour will be changed.

Ian

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dennis Clarke]

> Andrew Haley wrote:
>> On 02/10/2010 04:44 PM, Dr. David Kirkby wrote:
>>> According to
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
>>>
>>> -std=foobar
>>>
>>>
>>> `gnu9x'
>>>     GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
>>> this will become the default. The name `gnu9x' is deprecated.
>>>
>>> I really can not understand the logic of this. Why not default to ISO
>>> C99 and let people enable GNUisms if they wish to? Then code should be
>>> more portable across different compilers. With the GNUisms allowed by
>>> default, it will make porting code more difficult to other stricter
>>> compilers.
>>
>> This reasoning would make perfect sense if the primary goal of gcc's
>> users was to write code to be ported to other compilers.
>
> I thought gcc's primary aim was to be a *C* compiler. That would suggest
> to me
> that enabling GNU extensions should not be the default, but an option.
>
> A lot of bugs are often discovered in code by testing on multiple
> compilers and
> multiple platforms. What one compiler misses, another finds. I could point
> you
> to various cases where the Sun compiler has rejected erroneous code that
> gcc has
> permitted. I'm sure you could no doubt find counter examples too.
>
> By generating code that should build with other compilers, problems can be
> detected more easily.
>
>> However,
>> many of GNU C's extensions are very useful, so it makes sense to have
>> them available by default.

  That seems to be a weak argument.

  The standards are useful and are in place for good reasons. Not the
least of which is that we can expect consistent code input files in a
given format and dialect based on well published and industry accepted
standards. The programming language, regardless if it be assembly, C,
Fortran or Cobol, must be portable and acceptable to any compiler that
complies with the published standards. Regardless of the vendor, be it
Sun/Oracle, IBM, Microsoft, Intel or Linus's abacus basement compiler
that he coded himself. If that compiler, a program which accepts as
input files in the form of C language sources, simply abides by those
published standards then we have a world where the student, the
professional programmer and the next generation of open source
contributors can live and work without the threat of single vendor rules
which limit freedom and stifle innovation. It is only a small step on
the slippery slope of non-standard "useful" things before we have code
that simply does not work anywhere else.

>> (Having said that, many of GNU C's
>> extensions are part of C99 anyway, so the difference is smaller than
>> with C89.)
>
> Personally I feel this is a bad decision, but I'm not a gcc developer.
>
> Dave

At the risk of a significant argument, I would state rather loudly that
any compiler which defaults to non-standard, regardless of usefulness, is
at fault.

-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Kevin P. Fleming]

Dr. David Kirkby wrote:

> I can't see how hackers can find it too hard to add an option, such as
> -allow-GNU-extensions, so they, and anyone reading the code, are well
> aware they are not writing C code, but some non-portable variant of it.

As it turns out, even many of GCC's extensions that are not part of C99
are now supported by other compilers because, as has been posted before,
they are so darn useful. That means that using them does not necessarily
make the code 'non portable', although it's not as portable as pure C99
would be.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dr. David Kirkby]

Alfred M. Szmidt wrote:
>    I thought gcc's primary aim was to be a *C* compiler. That would
>    suggest to me that enabling GNU extensions should not be the
>    default, but an option.
> 
> That is one of the goals, another goal is GCC is the compiler for the
> GNU system and its variant where we wish to make life easier for
> hackers by providing useful features, that might not be standard.
> 
> You can usually work around these problems by calling c99/c89 instead
> of calling gcc.
> 

I can't see how hackers can find it too hard to add an option, such as 
-allow-GNU-extensions, so they, and anyone reading the code, are well aware they 
are not writing C code, but some non-portable variant of it.

In contrast, permitting the extensions by default will lead people to be believe 
they are writing C code, whereas in fact they are not.



Dave

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Andrew Haley]

On 02/10/2010 05:25 PM, Dr. David Kirkby wrote:
> Andrew Haley wrote:
>> On 02/10/2010 04:44 PM, Dr. David Kirkby wrote:
>>> According to
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
>>>
>>> -std=foobar
>>>
>>> `gnu9x'
>>>     GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
>>> this will become the default. The name `gnu9x' is deprecated.
>>>
>>> I really can not understand the logic of this. Why not default to ISO
>>> C99 and let people enable GNUisms if they wish to? Then code should be
>>> more portable across different compilers. With the GNUisms allowed by
>>> default, it will make porting code more difficult to other stricter
>>> compilers.
>>
>> This reasoning would make perfect sense if the primary goal of gcc's
>> users was to write code to be ported to other compilers. 
> 
> I thought gcc's primary aim was to be a *C* compiler.

The actual goals of gcc are here:
http://gcc.gnu.org/gccmission.html

Andrew.

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Alfred M. Szmidt]

   I thought gcc's primary aim was to be a *C* compiler. That would
   suggest to me that enabling GNU extensions should not be the
   default, but an option.

That is one of the goals, another goal is GCC is the compiler for the
GNU system and its variant where we wish to make life easier for
hackers by providing useful features, that might not be standard.

You can usually work around these problems by calling c99/c89 instead
of calling gcc.

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Dr. David Kirkby]

Andrew Haley wrote:
> On 02/10/2010 04:44 PM, Dr. David Kirkby wrote:
>> According to
>>
>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
>>
>> -std=foobar
>>
>>
>> `gnu9x'
>>     GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
>> this will become the default. The name `gnu9x' is deprecated.
>>
>> I really can not understand the logic of this. Why not default to ISO
>> C99 and let people enable GNUisms if they wish to? Then code should be
>> more portable across different compilers. With the GNUisms allowed by
>> default, it will make porting code more difficult to other stricter
>> compilers.
> 
> This reasoning would make perfect sense if the primary goal of gcc's
> users was to write code to be ported to other compilers. 

I thought gcc's primary aim was to be a *C* compiler. That would suggest to me 
that enabling GNU extensions should not be the default, but an option.

A lot of bugs are often discovered in code by testing on multiple compilers and 
multiple platforms. What one compiler misses, another finds. I could point you 
to various cases where the Sun compiler has rejected erroneous code that gcc has 
permitted. I'm sure you could no doubt find counter examples too.

By generating code that should build with other compilers, problems can be 
detected more easily.

> However,
> many of GNU C's extensions are very useful, so it makes sense to have
> them available by default.  (Having said that, many of GNU C's
> extensions are part of C99 anyway, so the difference is smaller than
> with C89.)

Personally I feel this is a bad decision, but I'm not a gcc developer.

Dave

Re: Why is gcc going to default to "GNU dialect of ISO C99?"

[Andrew Haley]

On 02/10/2010 04:44 PM, Dr. David Kirkby wrote:
> According to
> 
> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
> 
> -std=foobar
> 
> 
> `gnu9x'
>     GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
> this will become the default. The name `gnu9x' is deprecated.
> 
> I really can not understand the logic of this. Why not default to ISO
> C99 and let people enable GNUisms if they wish to? Then code should be
> more portable across different compilers. With the GNUisms allowed by
> default, it will make porting code more difficult to other stricter
> compilers.

This reasoning would make perfect sense if the primary goal of gcc's
users was to write code to be ported to other compilers.  However,
many of GNU C's extensions are very useful, so it makes sense to have
them available by default.  (Having said that, many of GNU C's
extensions are part of C99 anyway, so the difference is smaller than
with C89.)

Andrew.

Why is gcc going to default to "GNU dialect of ISO C99?"

[Dr. David Kirkby]

According to

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options

-std=foobar


`gnu9x'
     GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC, this will 
become the default. The name `gnu9x' is deprecated.

I really can not understand the logic of this. Why not default to ISO C99 and 
let people enable GNUisms if they wish to? Then code should be more portable 
across different compilers. With the GNUisms allowed by default, it will make 
porting code more difficult to other stricter compilers.

Dave