GCC/K&R Incompatibility

[Thomas Scrace]

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?

Tom

 

[Ben Pfaff]

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/getline.html
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 Bacarisse]

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 Bacarisse]

getline() is standardized by POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getline.html
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 Pfaff]

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.

 

[Seebs]

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

 

[Ben Bacarisse]

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!

 

[James Kuyper]

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.

 

[Jorgen Grahn]

.

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

 

[Thomas Scrace]

Some interesting responses here, thanks.

FWIW I used the standard gcc that came with Fedora 14 with no flags or
non-standard options. My point is really just that for a beginning programmer
learning C for the first time from K&R this could (if using the right version of
GCC) present a big gotcha, for which there is no blindingly obvious solution. I
was able to figure out roughly what was happening, but I am not a beginning
programmer.

I take all the points on board, but it seems to me that making a function called
getline(), which clearly clashes with the foundational text of the language, was
perhaps a bit misguided.

 

[Jorgen Grahn]

Some interesting responses here, thanks.

FWIW I used the standard gcc that came with Fedora 14 with no flags or
non-standard options.

I wish it was easier for new users to realize how gcc and Gnu libc
controls standards compliance. It's stated clearly in the manual, but
it's not obvious that you have to do anything about it.

My point is really just that for a beginning programmer
learning C for the first time from K&R this could (if using the right version of
GCC) present a big gotcha, for which there is no blindingly obvious solution. I
was able to figure out roughly what was happening, but I am not a beginning
programmer.

It's unfortunate, but the only solution is a new edition of K&R, or a
mention in the errata (not as an error, but a note for users of POSIX
systems.)

Also remember that your book is from 1988. That's more than half the
lifetime of the C language, back when SunOS was BSD-based and the
coolest thing you could have at home was an Amiga 500 with 512KB of
RAM[1].

You need to expect some things to change over the decades, even for C.

/Jorgen

[1] All this is an approximation only.

 

[Thomas Scrace]

It's unfortunate, but the only solution is a new edition of K&R

Perhaps that is the simplest solution; it has been, as you point out, quite a
while since the last one.

 

[Michael Press]

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.

In addition to -std=•••, which are the right options?

 

[James Kuyper]

In addition to -std=•••, which are the right options?

You also need -pedantic to get all of the required semantics, and a
sufficient number of -W options to get all of the mandatory diagnostics.
I use -Wall -Wpointer-arith -Wcast-align -Wstrict-prototypes
-Wmissing-prototypes, but I don't remember what's the minimum subset of
those options needed to ensure that all mandatory diagnostics actually
occur.

If your question is the result of you being aware of some way in which
it fails to be fully-conforming, even with all appropriate options
selected, I wouldn't be surprised - no compiler's perfect. Could you
tell us what that way is?

 

[Michael Press]

You also need -pedantic to get all of the required semantics, and a
sufficient number of -W options to get all of the mandatory diagnostics.
I use -Wall -Wpointer-arith -Wcast-align -Wstrict-prototypes
-Wmissing-prototypes, but I don't remember what's the minimum subset of
those options needed to ensure that all mandatory diagnostics actually
occur.

If your question is the result of you being aware of some way in which
it fails to be fully-conforming, even with all appropriate options
selected, I wouldn't be surprised - no compiler's perfect. Could you
tell us what that way is?

I asked purely for information and instruction:
how to compile standard C (your term) with gcc.

I read descriptions the warnings you listed and understand them.

 

[Harald van Dijk]

You also need -pedantic to get all of the required semantics, and a
sufficient number of -W options to get all of the mandatory diagnostics.

-std=* gives all the required semantics, and -pedantic gets you all
the mandatory diagnostics. -W* enables extra warnings, some of which
are very useful, but all the ones that the standard requires are
already enabled by -pedantic.

Instead of -pedantic, if you write pure ISO C, you might also consider
-pedantic-errors. Pretty much all of the diagnostics that the standard
requires are hard errors in _some_ other conforming compiler. OTOH, -
pedantic-errors is a bad idea if you know what you're doing when
you're going beyond what the standard allows.

 

[Michael Press]

-std=* gives all the required semantics, and -pedantic gets you all
the mandatory diagnostics. -W* enables extra warnings, some of which
are very useful, but all the ones that the standard requires are
already enabled by -pedantic.

Instead of -pedantic, if you write pure ISO C, you might also consider
-pedantic-errors. Pretty much all of the diagnostics that the standard
requires are hard errors in _some_ other conforming compiler. OTOH, -
pedantic-errors is a bad idea if you know what you're doing when
you're going beyond what the standard allows.

Thank you. I use -Wall -pedantic, and fix all warnings.

Also like to use -std=c99 so I can write for(int k = 0; ...).
Keeping index names sorted out is much easier.