Ping E Sossman

[Ben Bacarisse]

I thought all Unix and Unix like systems did this. If not, a
statically linked symbol should take precedence over one form a
dynamic library.

The problem is not the external symbol and the linker. As you say,
you'll get your version over the glibc one if things ever get that far!

The problem is the declaration in stdio.h. It is supposed to be turned
on by #define _GNU_SOURCE but it appears to persist even when that
symbol is undefined. I think this is a plain bug -- unrelated to choice
of name. I may have misunderstood how the feature test macros work, but
they don't behave as I'd expect from the documentation.

There is supposed to be no such declaration if you compile with -std=c89
-pedantic but that appears not to be the case.

 

[Keith Thompson]

It depends if you see programming as a profession or not.
Professionals take an interest in the field, they submit articles to
journals, they keep associations going, they joid ad hoc committees to
address problems, they go to schools and universities to talk to young
people interested in joining the profession. Sometimes expenses are
paid, sometimes they are not, time is seldom compensated by the hour.

Non-professionals don't. They do the job contracted, then go home and
forget all about it.

Eric wrote a function, giving it the perfectly reasonable name
"getline", and posted it somewhere "just as an example of what one
particular Everyone had done". Since the source is freely available,
anyone who has a problem with the name can change it. He was under
no obligation to post it, and is under no more obligation to maintain
it than he would be if he had merely posted it in an article here.

Calling him "non-professional" because of that is absurd.

 

[ImpalerCore]

It depends if you see programming as a profession or not.
Professionals take an interest in the field, they submit articles to
journals, they keep associations going, they joid ad hoc committees to
address problems, they go to schools and universities to talk to young
people interested in joining the profession. Sometimes expenses are
paid, sometimes they are not, time is seldom compensated by the hour.

Non-professionals don't. They do the job contracted, then go home and
forget all about it.

It depends if you see family as a profession or not. Fathers take an
interest in the family, they submit to listening to their wife, to
make time to play and interact with their kids, they join ad hoc
sports leagues that mentor their children, and take in interest in
their dreams even if it doesn't match their own. Expenses are never
paid, but the compensation is more than worth the time spent.

Others don't. They do the job contracted, then go to work and forget
all about it.

 

[Ian Collins]

The problem is not the external symbol and the linker. As you say,
you'll get your version over the glibc one if things ever get that far!

The problem is the declaration in stdio.h. It is supposed to be turned
on by #define _GNU_SOURCE but it appears to persist even when that
symbol is undefined. I think this is a plain bug -- unrelated to choice
of name. I may have misunderstood how the feature test macros work, but
they don't behave as I'd expect from the documentation.

Ah, I see the problem now. I didn't realise they'd done something that bad!

 

[Keith Thompson]

Ah, I see the problem now. I didn't realise they'd done something that bad!

At least on my system, it doesn't appear that they have.

On Ubuntu 9.04, gcc 4.3.3, libc6 and libc6-dev 2.9-4ubuntu6.2, the
following program:

#include <stdio.h>

int main(void)
{
char **lineptr = NULL;
size_t *n = NULL;
FILE *stream = NULL;

if (0) getline(lineptr, n, stream);
return 0;
}

produces a warning "implicit declaration of function ‘getline’"
when compiled with "gcc -c -std=c99". Adding "-D_GNU_SOURCE"
makes the warning go away. Conclusion: glibc's getline function
is visible in <stdio.h> if and only if _GNU_SOURCE is defined.

 

[Seebs]

It depends if you see programming as a profession or not.

I don't think so. I am passionate about code quality, but I don't spend much
time coding workarounds to other people's bugs unless someone's paying me to
or the bug affects me. Ultimately, if my code was correct, and remains
correct, and someone's broken a library somewhere, I feel it's up to the
library maintainer to fix the problem. I'll put in workarounds if I need
them, but not otherwise. I do not feel that the profession's long-term
interests are advanced by promoting a culture of ad-hoc standardization of
local color without any attention given to namespace issues, nor are they
advanced by a policy that people with lots of customers can simply ignore
specifications and do whatever they want.

In short, from my point of view, giving in to a bad implementation decision
(and grabbing a commonly-used name that is DEFINITELY not in implementation
namespace is clearly a "bad implementation decision") is anti-professional.

-s

 

[Ben Bacarisse]

At least on my system, it doesn't appear that they have.

On Ubuntu 9.04, gcc 4.3.3, libc6 and libc6-dev 2.9-4ubuntu6.2, the
following program:

#include <stdio.h>

int main(void)
{
char **lineptr = NULL;
size_t *n = NULL;
FILE *stream = NULL;

if (0) getline(lineptr, n, stream);
return 0;
}

produces a warning "implicit declaration of function ‘getline’"
when compiled with "gcc -c -std=c99". Adding "-D_GNU_SOURCE"
makes the warning go away. Conclusion: glibc's getline function
is visible in <stdio.h> if and only if _GNU_SOURCE is defined.

It's more complex than I made out. I get the same behaviour as you do
for the above. Indeed, I never have any trouble if I turn on one of the
standard C modes (and I should have said that -- its important). The
trouble comes when trying to exclude getline as per the manual. I'd
expect

#undef _GNU_SOURCE
#include <stdio.h>

char getline(char **lineptr, size_t *n, FILE *stream);

to be fine since the documentation suggests that getline is predicated
on _GNU_SOURCE (and only _GNU_SOURCE) being defined, but instead I get:

t.c:4: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here

Of course, if you happen to have a type compatible getline, it all works
and you get your version rather than glibc's version, but that's not
really the issue.

 

[Keith Thompson]

It's more complex than I made out. I get the same behaviour as you do
for the above. Indeed, I never have any trouble if I turn on one of the
standard C modes (and I should have said that -- its important). The
trouble comes when trying to exclude getline as per the manual. I'd
expect

#undef _GNU_SOURCE
#include <stdio.h>

char getline(char **lineptr, size_t *n, FILE *stream);

to be fine since the documentation suggests that getline is predicated
on _GNU_SOURCE (and only _GNU_SOURCE) being defined, but instead I get:

t.c:4: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here

Of course, if you happen to have a type compatible getline, it all works
and you get your version rather than glibc's version, but that's not
really the issue.

I can't reproduce the problem you're describing. I don't get any
diagnostics for the above, and with a slightly larger test case:

% cat c.c
#undef _GNU_SOURCE

#include <stdio.h>

double getline(double x) {
return x * x;
}

int main(void)
{
printf("getline(1.5) = %.2f\n", getline(1.5));
return 0;
}
% gcc c.c -o c && ./c
getline(1.5) = 2.25
% gcc -std=c99 -pedantic -Wall -Wextra -O3 c.c -o c && ./c
getline(1.5) = 2.25
%

 

[Ben Bacarisse]

I can't reproduce the problem you're describing.

That's interesting. I'm using gcc 4.4.3 (Ubuntu 4.4.3-4ubuntu5) and
libc6-dev version 2.11.1-0ubuntu7.2 and don't remember this problem
cropping up before. It may be a recent regression, unless I've somehow
messed up my installation, of course.

I don't get any
diagnostics for the above, and with a slightly larger test case:

% cat c.c
#undef _GNU_SOURCE

#include <stdio.h>

double getline(double x) {
return x * x;
}

int main(void)
{
printf("getline(1.5) = %.2f\n", getline(1.5));
return 0;
}
% gcc c.c -o c && ./c
getline(1.5) = 2.25
% gcc -std=c99 -pedantic -Wall -Wextra -O3 c.c -o c && ./c
getline(1.5) = 2.25

$ cat c.c
#undef _GNU_SOURCE

#include <stdio.h>

double getline(double x) {
return x * x;
}

int main(void)
{
printf("getline(1.5) = %.2f\n", getline(1.5));
return 0;
}
$ gcc c.c -o c && ./c
c.c:5: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
$ gcc -std=c99 -pedantic -Wall -Wextra -O3 c.c -o c && ./c
getline(1.5) = 2.25

That last is expected -- I've never seen this problem with one of the
standard C settings.

 

[Keith Thompson]

That's interesting. I'm using gcc 4.4.3 (Ubuntu 4.4.3-4ubuntu5) and
libc6-dev version 2.11.1-0ubuntu7.2 and don't remember this problem
cropping up before. It may be a recent regression, unless I've somehow
messed up my installation, of course.


$ cat c.c
#undef _GNU_SOURCE

#include <stdio.h>

double getline(double x) {
return x * x;
}

int main(void)
{
printf("getline(1.5) = %.2f\n", getline(1.5));
return 0;
}
$ gcc c.c -o c && ./c
c.c:5: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
$ gcc -std=c99 -pedantic -Wall -Wextra -O3 c.c -o c && ./c
getline(1.5) = 2.25

That last is expected -- I've never seen this problem with one of the
standard C settings.

I see the same thing with a later version, Ubuntu 10.04, gcc 4.4.3,
libc6 2.11.1-0ubuntu. A bit of Googling indicates that it's a known
issue. <https://bugzilla.redhat.com/show_bug.cgi?id=493941> says:

getline is a standard POSIX 2008 function and we do want POSIX C
2008 stuff by default. If you don't like it, choose a different
namespace or rename your functions.

And in fact getline() is documented in IEEE Std 1003.1-2008.
So making it visible by default if you don't specify ISO C
conformance is not entirely unreasonable.

In retrospect, it would have been nice if all the POSIX-specific
functions were declared in POSIX-specific headers, but it's too
late to fix that (at least without breaking tons of existing code).

 

[Malcolm McLean]

It depends if you see family as a profession or not.  Fathers take an
interest in the family, they submit to listening to their wife, to
make time to play and interact with their kids, they join ad hoc
sports leagues that mentor their children, and take in interest in
their dreams even if it doesn't match their own.  Expenses are never
paid, but the compensation is more than worth the time spent.

Others don't.  They do the job contracted, then go to work and forget
all about it.

Exactly. All non-dysfunctional families are like the first, because
people are interested in their own families. Unless there is divorce
or something, they don't need a contract telling them to take Junior
to football practice.

However most people don't have that attitude to their work. They do
eight hours at the car factory, come home, and turn on the telly.
That's legitimate. However professionals are different.

 

[Seebs]

getline is a standard POSIX 2008 function and we do want POSIX C
2008 stuff by default. If you don't like it, choose a different
namespace or rename your functions.

GAK! Okay, I take it back. glibc isn't stupid, POSIX is.

-s

 

[ImpalerCore]

Exactly. All non-dysfunctional families are like the first, because
people are interested in their own families. Unless there is divorce
or something, they don't need a contract telling them to take Junior
to football practice.

However most people don't have that attitude to their work. They do
eight hours at the car factory, come home, and turn on the telly.
That's legitimate. However professionals are different.

I feel that it's quite difficult to maintain your level of
professionalism and still keep healthy family commitments (though I
think it'll probably wane in time). When I was single I think I could
attempt to do those things, and spent much time outside the classroom
on extra reading/coding/helping other students. But now I know I
certainly don't make time to do most of those things you listed. I
guess that would make me a casual programmer, and when I think about
it, I think I probably am now. I still tinker a few hours outside of
work (usually at the cost of sleep), so I can't imagine trying to do
both effectively.

Best regards,
John D.

 

[Jorgen Grahn]

.

It's more complex than I made out. I get the same behaviour as you do
for the above. Indeed, I never have any trouble if I turn on one of the
standard C modes (and I should have said that -- its important). The
trouble comes when trying to exclude getline as per the manual. I'd
expect

#undef _GNU_SOURCE
#include <stdio.h>

char getline(char **lineptr, size_t *n, FILE *stream);

to be fine since the documentation suggests that getline is predicated
on _GNU_SOURCE (and only _GNU_SOURCE) being defined, but instead I get:

....

You cannot expect that having _GNU_SOURCE defined and then undefing it
is the same thing as it never being enabled in the first place.

Internally in stdio.h it's enabled by _USE_GNU, which in turn is
enabled back in features.h -- which by the way documents which defines
you may safely use to enable non-standard stuff.

So the bottom line for me is: if you tell the compiler "I want all
kinds of odd GNU extensions", you'd better be prepared to get all
kinds of odd GNU extensions ...

I always compile in strict mode, and when I need something
non-standard I enable it (using one of the BSD or POSIX defines; I
never or almost never enable GNU stuff because I cannot remember what
that stuff is).

/Jorgen

 

[Ben Bacarisse]

...

You cannot expect that having _GNU_SOURCE defined and then undefing it
is the same thing as it never being enabled in the first place.

Except that at least some of the documentation leads me to expect
exactly that!

The man page for getline says:

#define _GNU_SOURCE
#include <stdio.h>

ssize_t getline(char **lineptr, size_t *n, FILE *stream);

and the man page for the feature test macros says:

In a few cases, manual pages use a shorthand for expressing the
feature test macro requirements (this example from readahead(2)):

#define _GNU_SOURCE
#include <fcntl.h>

ssize_t readahead(int fd, off64_t *offset, size_t count);

This format is employed in cases where only a single feature test
macro can be used to expose the function declaration, and that
macro is not defined by default.

The reality seems to be that _GNU_SOURCE is defined by default and not
getting this declaration is therefore not as simple as never
defining _GNU_SOURCE. By trying all 11 feature macros I've found
that it seems to be included unless __STRING_ANSI__ is defined. Then,
and only then, is it controlled by GNU_SOURCE. Curiously, the same
method does not work for other declarations whose documentation looks
similar.

Internally in stdio.h it's enabled by _USE_GNU, which in turn is
enabled back in features.h -- which by the way documents which defines
you may safely use to enable non-standard stuff.

I don't think the documentation is up-to-date. In fact, that is
probably the only issue here. The docs suggest that this feature needs
to be turned on whereas it needs to be turned off.

Your "by the way" suggests that I just needed to RTFM and I've have been
enlightened, but I am an avid reader of manuals and it was the manual
that led me astray.

So the bottom line for me is: if you tell the compiler "I want all
kinds of odd GNU extensions", you'd better be prepared to get all
kinds of odd GNU extensions ...

I always compile in strict mode, and when I need something
non-standard I enable it (using one of the BSD or POSIX defines; I
never or almost never enable GNU stuff because I cannot remember what
that stuff is).

That is, in fact, what I do. I was simply trying to explain what other
people seem to have seen so as to shed some light on when and how you
get this declaration.

 

[Ian Collins]

I feel that it's quite difficult to maintain your level of
professionalism and still keep healthy family commitments (though I
think it'll probably wane in time).

That depends how you define professionalism. My definition happens to
differ from Malcolm McLean.

When I was single I think I could
attempt to do those things, and spent much time outside the classroom
on extra reading/coding/helping other students. But now I know I
certainly don't make time to do most of those things you listed.

For several years the things he listed were part of my remit as an
Engineering Director. Did doing them make me more of a professional? I
don't think so. I could have claimed back the hours ans still done a
basic 40 hour week. But if I was the kind of person who did that, I'd
never have been in that job in the first place!

I
guess that would make me a casual programmer, and when I think about
it, I think I probably am now. I still tinker a few hours outside of
work (usually at the cost of sleep), so I can't imagine trying to do
both effectively.

Don't put your self down. I used to work only when my kids were at
school or asleep, but my professionalism didn't slip.