[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

GCC/K&R Incompatibility

Thomas Scrace

4/14/2011 4:29:00 PM

19 Answers

William Ahern

4/14/2011 5:22:00 PM

0

Thomas Scrace <tgs@gmail.com> wrote:
> Hi all,

> I am working through K&R, and I got to section 1.9, which includes an example
> that creates a function 'getline'. I duly typed it all up, and compiled it with
> gcc. Surprisingly I got an error telling me of incompatible types for this
> function.

> It turns out that GNU's C library now includes a function called getline, and
> since I was including stdio.h, this was the cause of the problem. I recompiled
> using c89, and everything worked fine.

> My question is this: should we not make an effort to keep the modern C toolchain
> and library compatible with the great K&R, unless doing so would create an even
> more undesirable outcome?

getline() was added to the POSIX standard recently after having been in
glibc for many years. If you want standards conformance you usually have to
specify it, rather than vice-versa. The ship you're looking for sailed away
a long time ago.

Ben Pfaff

4/14/2011 5:26:00 PM

0

Thomas Scrace <tgs@gmail.com> writes:

> I am working through K&R, and I got to section 1.9, which includes an
> example that creates a function 'getline'. I duly typed it all up, and
> compiled it with gcc. Surprisingly I got an error telling me of
> incompatible types for this function.
>
> It turns out that GNU's C library now includes a function called
> getline, and since I was including stdio.h, this was the cause of the
> problem. I recompiled using c89, and everything worked fine.
>
> My question is this: should we not make an effort to keep the modern C
> toolchain and library compatible with the great K&R, unless doing so
> would create an even more undesirable outcome?

getline() is standardized by POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
Your GCC installation must default to enabling POSIX features,
and so it isn't too surprising that declaring a function that
conflicts with POSIX would provoke a diagnostic.
--
Ben Pfaff
http://be...

Ben Bacarisse

4/14/2011 5:54:00 PM

0

Thomas Scrace <tgs@gmail.com> writes:

> I am working through K&R, and I got to section 1.9, which includes an
> example that creates a function 'getline'. I duly typed it all up, and
> compiled it with gcc. Surprisingly I got an error telling me of
> incompatible types for this function.
>
> It turns out that GNU's C library now includes a function called
> getline, and since I was including stdio.h, this was the cause of the
> problem. I recompiled using c89, and everything worked fine.
>
> My question is this: should we not make an effort to keep the modern C
> toolchain and library compatible with the great K&R, unless doing so
> would create an even more undesirable outcome?

Well it is compatible is it not? Your previous paragraph confirms it.
Your question seems to be something ore like "should gcc with default
flags be compatible with K&R". I'd say "yes" but simply because I'd
rather have "-std=c99 -pedantic" be the default. Of course, K&R2 is C89
so I'm not 100% sure that those flags won't cause a problem.

--
Ben.

Ben Bacarisse

4/14/2011 5:56:00 PM

0

Ben Pfaff <blp@cs.stanford.edu> writes:
<snip>
> getline() is standardized by POSIX:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
> Your GCC installation must default to enabling POSIX features,

Must? I can see that there is an argument that the cc command should
but I can't see why that should extend beyond that.

<snip>
--
Ben.

Martin Ambuhl

4/14/2011 6:00:00 PM

0

On 4/14/2011 12:29 PM, Thomas Scrace wrote:
> Hi all,
>
> I am working through K&R, and I got to section 1.9, which includes an
> example that creates a function 'getline'. I duly typed it all up, and
> compiled it with gcc. Surprisingly I got an error telling me of
> incompatible types for this function.
>
> It turns out that GNU's C library now includes a function called
> getline, and since I was including stdio.h, this was the cause of the
> problem. I recompiled using c89, and everything worked fine.

You could have used any of the -std= options which specify a non-gnuC
compilation.

> My question is this: should we not make an effort to keep the modern C
> toolchain and library compatible with the great K&R, unless doing so
> would create an even more undesirable outcome?

If you insist on using gcc with options for GnuC (non-standard
extensions of C, one of which is the default) in its various versions
instead of with options for one of the (past and present) standard C
forms, you get what you ask for. There is nothing sacred about the
names for non-standard functions that K&R contains. There is a problem
that gcc in its default mode allows the implementation to invade the
user namespace.

blp

4/14/2011 6:37:00 PM

0

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Ben Pfaff <blp@cs.stanford.edu> writes:
>> getline() is standardized by POSIX:
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
>> Your GCC installation must default to enabling POSIX features,
>
> Must? I can see that there is an argument that the cc command should
> but I can't see why that should extend beyond that.

It must, in the sense that its behavior allows me to infer that
it *does*. My statement did not intentionally judge whether it
*should* behave that way.
--
"Am I missing something?"
--Dan Pop

Seebs

4/14/2011 6:55:00 PM

0

On 2011-04-14, Thomas Scrace <tgs@gmail.com> wrote:
> My question is this: should we not make an effort to keep the modern C
> toolchain and library compatible with the great K&R,

It's not obvious which "we" would do so. I do think that creating a function
named "getline()" was a classic example of incandescent stupidity, though.
I believe it was standardized by POSIX, but I have no idea where they got the
idea. It's... Pretty stupid, really. That name was very widely used, and
was clearly in the user's namespace.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seeb... <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/...(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Ben Bacarisse

4/14/2011 7:46:00 PM

0

blp@cs.stanford.edu (Ben Pfaff) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Ben Pfaff <blp@cs.stanford.edu> writes:
>>> getline() is standardized by POSIX:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
>>> Your GCC installation must default to enabling POSIX features,
>>
>> Must? I can see that there is an argument that the cc command should
>> but I can't see why that should extend beyond that.
>
> It must, in the sense that its behavior allows me to infer that
> it *does*. My statement did not intentionally judge whether it
> *should* behave that way.

Oh, I see -- "must" as in "it must be the case that". The other meaning
of "your X must Y" -- an obligation or compulsion on X to do Y -- is
hard for me to suppress even now that I know your meaning!

--
Ben.

James Kuyper

4/15/2011 1:02:00 AM

0

On 04/14/2011 12:29 PM, Thomas Scrace wrote:
> Hi all,
>
> I am working through K&R, and I got to section 1.9, which includes an example
> that creates a function 'getline'. I duly typed it all up, and compiled it with
> gcc. Surprisingly I got an error telling me of incompatible types for this
> function.
>
> It turns out that GNU's C library now includes a function called getline, and
> since I was including stdio.h, this was the cause of the problem. I recompiled
> using c89, and everything worked fine.
>
> My question is this: should we not make an effort to keep the modern C toolchain
> and library compatible with the great K&R, unless doing so would create an even
> more undesirable outcome?

The key thing to realize is that what gcc implements, by default, is a
language known as Gnu-C. It's derived from C, and has lots of
similarities to C, but it's a significantly different language.
Criticizing Gnu-C for incompatibility with the C language as described
by K&R is only slightly less pointless than criticizing APL for being
incompatible with perl.

In non-default mode, by choosing the right options, you can ask gcc to
perform as a fully-conforming C90 compiler, and with different options
it is a nearly-conforming C99 compiler. The fact that you didn't use
those options was your decision, not something you can hold gcc
responsible for. Gnu-C is gcc's default language because they would
prefer it if if you would use Gnu-C, rather than standard C.

--
James Kuyper

Jorgen Grahn

4/15/2011 11:09:00 PM

0

On Fri, 2011-04-15, James Kuyper wrote:
....
> Gnu-C is gcc's default language because they would
> prefer it if if you would use Gnu-C, rather than standard C.

I haven't followed gcc politics closely, but I believe that statement
is less true today than maybe 10--15 years ago. Most of their weird
core language extensions are old, and as far as I can tell not widely
used.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .