compile error

[Ceriousmall]

Why is this program not compiling when the Gcc command is used . This
is a out of the K&R book, Gcc 4.4.4 Slackware 13.1 x86_64 . the error
is........conflicting types for 'getline'
note
previous declaration of 'getline' was here
It does however compile with the g++ command..........This is the
code..........................
..
..
/* program prints longest input line */
#include <stdio.h>

#define MAXLINE 1000 /* maximum input line size */

int getline(char line[], int maxline);
void copy(char to[], char from[]);

int main(void)
{
int len; /* current line length */
int max; /* maximum length seen so far */
char line[MAXLINE]; /* current input line */
char longest[MAXLINE]; /* longest line saved here */

max = 0;

while ((len = getline(line, MAXLINE)) > 0)
if (len > max) {
max = len;
copy(longest, line);
}
if (max > 0) /* there was a line */
printf("%s", longest);

return 0;
}

/* getline: read a line into s, return length */
int getline(char s[], int lim)
{
int c, i;

for (i = 0; i < lim-1 && (c = getchar()) != EOF && c != '\n'; ++i)
s = c;
if (c == '\n') {
s = c;
++i;
}
s = '\0';

return i;
}

/* copy: copy 'from' into 'to'; assume to is big enough */
void copy(char to[], char from[])
{
int i;

i = 0;

while ((to = from ) != '\0')
++i;
}

 

[Ian Collins]

Why is this program not compiling when the Gcc command is used . This
is a out of the K&R book, Gcc 4.4.4 Slackware 13.1 x86_64 . the error
is........conflicting types for 'getline'

Your system headers probably do a naughty and declare their own getline
in <stdio.h>.

Try invoking gcc in a conforming mode (gcc -ansi -pedantic -Wall).

 

[Seebs]

Why is this program not compiling when the Gcc command is used . This
is a out of the K&R book, Gcc 4.4.4 Slackware 13.1 x86_64 . the error
is........conflicting types for 'getline'

The reason is that the glibc developers are utterly and totally opposed
to any kind of basic sanity in their development process.

Basically, glibc declares a function with the name "getline" and makes it
part of the system implementation. It does this despite the fact that
the name in question was widely used (including, as you note, being used
in examples in K&R) and was in a namespace reserved for users.

This is, I believe, the single dumbest implementation decision I have ever
seen in any C compiler or C library. And that is, I will point out, a
field with very stiff competition.

-s

 

[Seebs]

getline() is a recent addition to the POSIX 2008 standard that is being
exposed to you. Everybody who has their own implementation of getline()
and does not ensure that POSIX functions are not made visible (or who
needs other POSIX functions from <stdio.h>) will get burned by it until
they rename their function.

....

I take back what I said about glibc.

This is the single stupidest standardization decision I have ever seen. It
would never have occurred to me that the POSIX people could do something
*this* stupid. ... And yes, I know how extreme a statement that is.

-s

 

[Ian Collins]

....

I take back what I said about glibc.

This is the single stupidest standardization decision I have ever seen. It
would never have occurred to me that the POSIX people could do something
*this* stupid. ... And yes, I know how extreme a statement that is.

This isn't the only POSIX function to be found in <stdio.h>. The
problem is gcc includes POSIX extensions in its default mode.

 

[Keith Thompson]

This isn't the only POSIX function to be found in <stdio.h>. The
problem is gcc includes POSIX extensions in its default mode.

How much of a problem is that, though? I suspect that most gcc users
would rather have POSIX available by default than not.

(I really wish POSIX had been able to avoid adding non-standard
functions to the C standard headers, but some of those headers,
including what are now POSIX-specific declarations, predate the
C standard.)

 

[Ian Collins]

How much of a problem is that, though? I suspect that most gcc users
would rather have POSIX available by default than not.

In the context of this post it is the problem!

 

[Seebs]

This isn't the only POSIX function to be found in <stdio.h>. The
problem is gcc includes POSIX extensions in its default mode.

No, the problem is POSIX inventing a new function and giving it a name
that was not only in the user's namespace, *but very widely used*. In
programs that had been running on UNIX machines for years.

-s

 

[Ian Collins]

No, the problem is POSIX inventing a new function and giving it a name
that was not only in the user's namespace, *but very widely used*. In
programs that had been running on UNIX machines for years.

Did they define a new function, or standardise existing (glibc)
practice? I've never used getline, but I'm sure it has been 'standard"
on Linux for a long time.

 

[Seebs]

Did they define a new function, or standardise existing (glibc)
practice? I've never used getline, but I'm sure it has been 'standard"
on Linux for a long time.

Sort of. If you look at the dozens of compilation problems introduced by
this, the thing is that a lot of GNU tools *provide their own*... using a
standard interface.

Which is different from this one.

-s

 

[Jorgen Grahn]

This isn't the only POSIX function to be found in <stdio.h>. The
problem is gcc includes POSIX extensions in its default mode.

It should be well-known by now that you shouldn't use gcc's default
mode. Say -ansi or -std=c99, and the problem goes away.

I don't know why they haven't made -ansi their default. For a long
time I believed it was so ancient pre-ANSI code would compile, but it
turns out that was the -traditional switch, which has been removed
some time during the last decade.

/Jorgen

 

[Seebs]

It should be well-known by now that you shouldn't use gcc's default
mode. Say -ansi or -std=c99, and the problem goes away.

I don't know why they haven't made -ansi their default. For a long
time I believed it was so ancient pre-ANSI code would compile, but it
turns out that was the -traditional switch, which has been removed
some time during the last decade.

Of the last million or so lines of code I've built with gcc, I'd
guess less than 1% would have built with -ansi but not without it,
and well over 50% would not have built with -ansi but did by
default.

-s

 

[Kenny McCormack]

It should be well-known by now that you shouldn't use gcc's default
mode. Say -ansi or -std=c99, and the problem goes away.

And causes a bunch of other problems.

I don't know why they haven't made -ansi their default. For a long

Sure you do. For the same reason that the default mode of my car
doesn't require me to pump the pedals to make it go (in the manner that,
unfortunately, my bicycle does require).

 

[Nick Keighley]

How much of a problem is that, though?  I suspect that most gcc users
would rather have POSIX available by default than not.

really? why? gcc runs on plenty of non-Posix systems. I prefer my
compilers to be standard straight out of the box. The fact that none
of them are is another issue.

 

[Jorgen Grahn]

Of the last million or so lines of code I've built with gcc, I'd
guess less than 1% would have built with -ansi but not without it,
and well over 50% would not have built with -ansi but did by
default.

I guess it's not because you use those weird gcc-specific extensions
to the language, but because you actually use POSIX/BSD/etc stuff from
the libc?

I use -ansi in combination with -D_POSIX_SOURCE (or whatever it is I'm
using.) Seems much cleaner than trying to remember what not saying
anything actually means.

/Jorgen

 

[Tim Rentsch]

Of the last million or so lines of code I've built with gcc, I'd
guess less than 1% would have built with -ansi but not without it,
and well over 50% would not have built with -ansi but did by
default.

What fraction would have built with -ansi plus the relevant
defines to include POSIX functions?

What fraction would have built with -std=c99 plus the relevant
defines to include POSIX functions?

Hopefully at least one of those numbers is fairly large...

 

[Ian Collins]

What fraction would have built with -ansi plus the relevant
defines to include POSIX functions?

What fraction would have built with -std=c99 plus the relevant
defines to include POSIX functions?

Hopefully at least one of those numbers is fairly large...

Don't hold your breath if a good part of those million lines are the
Linux kernel!

 

[Seebs]

I guess it's not because you use those weird gcc-specific extensions
to the language, but because you actually use POSIX/BSD/etc stuff from
the libc?

I think I'm using some gcc-specific stuff, in fact, I'm actively selecting
some GNU extensions from glibc. So I actually run with -std=gnu99. But
I am sorta the Toolchain Guy for $dayjob, so I am the first point of contact
for basically all compiler problems. It's VERY rare for them to be caused
by the compiler including GNU extensions by default -- partially because
they're mostly things that have been compiled on such systems before. But
a TON of them wouldn't work if you didn't have those extensions on by default.

I think it really is the right default for most Linux-like systems, at
least. Most programs are not intended to be strictly conforming.

-s

 

[Ben Bacarisse]

I think I'm using some gcc-specific stuff, in fact, I'm actively selecting
some GNU extensions from glibc. So I actually run with -std=gnu99.

But that changes the language as well as the library. Is it not
possible to use std=c99 and turn on the library extensions with macros?
Maybe what you need is not exactly obtainable but that route, but it
often is.

But
I am sorta the Toolchain Guy for $dayjob, so I am the first point of contact
for basically all compiler problems. It's VERY rare for them to be caused
by the compiler including GNU extensions by default -- partially because
they're mostly things that have been compiled on such systems before. But
a TON of them wouldn't work if you didn't have those extensions on by default.

I think it really is the right default for most Linux-like systems, at
least. Most programs are not intended to be strictly conforming.

In terms of the library, no, but a great many more could be made
portable (between compilers) by relying only on library extensions
rather than language ones.

 

[Tom St Denis]

And causes a bunch of other problems.

If you use non-standard semantics.

Sure you do.  For the same reason that the default mode of my car
doesn't require me to pump the pedals to make it go (in the manner that,
unfortunately, my bicycle does require).

Get pedals with clips, then you're never "pumping" the pedal as every
part of the motion is involved in moving the bike.

Tom