Re: c89 broken on head?

2013-03-15 Thread Tijl Coosemans
On 2013-03-08 04:07, Eitan Adler wrote: > On 7 March 2013 18:03, Tijl Coosemans wrote: >> On 2013-03-07 22:36, Warner Losh wrote: >>> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... > Because it's the practical thing to do? Old code/ma

Re: c89 broken on head?

2013-03-08 Thread Eitan Adler
On 8 March 2013 12:40, Warner Losh wrote: > > On Mar 7, 2013, at 8:07 PM, Eitan Adler wrote: > >> On 7 March 2013 18:03, Tijl Coosemans wrote: >>> On 2013-03-07 22:36, Warner Losh wrote: On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: > On 2013-03-07 21:22, Tijl Coosemans wrote: >

Re: c89 broken on head?

2013-03-08 Thread Warner Losh
On Mar 7, 2013, at 8:07 PM, Eitan Adler wrote: > On 7 March 2013 18:03, Tijl Coosemans wrote: >> On 2013-03-07 22:36, Warner Losh wrote: >>> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: On 2013-03-07 21:22, Tijl Coosemans wrote: ... > Because it's the practical thing to do? Ol

Re: c89 broken on head?

2013-03-07 Thread Eitan Adler
On 7 March 2013 18:03, Tijl Coosemans wrote: > On 2013-03-07 22:36, Warner Losh wrote: >> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: >>> On 2013-03-07 21:22, Tijl Coosemans wrote: >>> ... Because it's the practical thing to do? Old code/makefiles can't possibly be expected to know

Re: c89 broken on head?

2013-03-07 Thread Tijl Coosemans
On 2013-03-07 22:36, Warner Losh wrote: > On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: >> On 2013-03-07 21:22, Tijl Coosemans wrote: >> ... >>> Because it's the practical thing to do? Old code/makefiles can't possibly >>> be expected to know about compilers of the future, while new code can be

Re: c89 broken on head?

2013-03-07 Thread Warner Losh
On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote: > On 2013-03-07 21:22, Tijl Coosemans wrote: > ... >> Because it's the practical thing to do? Old code/makefiles can't possibly >> be expected to know about compilers of the future, while new code can be >> expected to add -std=c11. > > I am not

Re: c89 broken on head?

2013-03-07 Thread Dimitry Andric
On 2013-03-07 21:22, Tijl Coosemans wrote: ... Because it's the practical thing to do? Old code/makefiles can't possibly be expected to know about compilers of the future, while new code can be expected to add -std=c11. I am not sure I buy that argument; if it were so, we should default to K&R

Re: c89 broken on head?

2013-03-07 Thread Tijl Coosemans
On 2013-03-07 20:28, Dimitry Andric wrote: > On 2013-03-07 18:24, Tijl Coosemans wrote: >> Whatever the command line arguments, running c89 almost always results in >> the following output. Anyone else seeing this? >> >> c89: illegal option -- 1 >> usage: c89 [-cEgOs] [-D name[=value]] ... [-I dire

Re: c89 broken on head?

2013-03-07 Thread David Chisnall
On 7 Mar 2013, at 19:28, Dimitry Andric wrote: >> Also, I seem to remember a discussion about making -std=gnu89 the default >> for clang when run as "cc", but nothing seems to have changed. Could this >> be picked up again, because there are in fact subtle semantic differences >> between gnu89 in

Re: c89 broken on head?

2013-03-07 Thread Dimitry Andric
On 2013-03-07 18:24, Tijl Coosemans wrote: Whatever the command line arguments, running c89 almost always results in the following output. Anyone else seeing this? c89: illegal option -- 1 usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ... [-o outfile] [-

c89 broken on head?

2013-03-07 Thread Tijl Coosemans
Whatever the command line arguments, running c89 almost always results in the following output. Anyone else seeing this? c89: illegal option -- 1 usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ... [-o outfile] [-U name] ... operand ... where operand