Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Ping E Sossman

Reply
Thread Tools

Ping E Sossman

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-31-2010
Ian Collins <(E-Mail Removed)> writes:

> On 08/31/10 07:38 PM, Seebs wrote:
>> On 2010-08-31, Malcolm McLean<(E-Mail Removed)> wrote:
>>> Breaking under gcc is a major nuisance.

>>
>> Not gcc. glibc.
>>
>>> Of course it's gcc's fault,
>>> but in the real world we can't inist on our own names against a
>>> recognised name like that.

>>
>> Yes, because if we make it clear to the glibc developers that they can
>> just grab any namespace they want, whenever they want, and we will NEVER
>> complain or suggest that it's a bug, that will encourage them to improve
>> their behavior!
>>
>> In BSD-land, the system libraries used weak references to solve this --
>> they'd provide the symbol, but allow you to provide your own which won,
>> and their declaration was behind feature tests. So, for instance, old
>> BSD libc had a symbol "end", but you could write a program using your
>> own and theirs didn't matter. ("end" was at the end of a block of memory,
>> of course.)

>
> 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.

--
Ben.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      08-31-2010
Malcolm McLean <(E-Mail Removed)> writes:
> On Aug 31, 10:38Â*am, Seebs <(E-Mail Removed)> wrote:
>> Anyway, I just don't see the point in expecting Eric to fix it. Â*If he ever
>> needs to run the code against newish glibc a lot, maybe he'll change it,
>> otherwise, why should he? Â*I'm not paying him to maintain that code, are you?
>>

> 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
ImpalerCore
Guest
Posts: n/a
 
      08-31-2010
On Aug 31, 6:19*am, Malcolm McLean <(E-Mail Removed)>
wrote:
> On Aug 31, 10:38*am, Seebs <(E-Mail Removed)> wrote:
>
> > Anyway, I just don't see the point in expecting Eric to fix it. *If he ever
> > needs to run the code against newish glibc a lot, maybe he'll change it,
> > otherwise, why should he? *I'm not paying him to maintain that code, are you?

>
> 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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-31-2010
On 08/31/10 11:34 PM, Ben Bacarisse wrote:
> Ian Collins<(E-Mail Removed)> writes:
>> On 08/31/10 07:38 PM, Seebs wrote:
>>>
>>> In BSD-land, the system libraries used weak references to solve this --
>>> they'd provide the symbol, but allow you to provide your own which won,
>>> and their declaration was behind feature tests. So, for instance, old
>>> BSD libc had a symbol "end", but you could write a program using your
>>> own and theirs didn't matter. ("end" was at the end of a block of memory,
>>> of course.)

>>
>> 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.


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

--
Ian Collins
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-31-2010
Ian Collins <(E-Mail Removed)> writes:
> On 08/31/10 11:34 PM, Ben Bacarisse wrote:
>> Ian Collins<(E-Mail Removed)> writes:
>>> On 08/31/10 07:38 PM, Seebs wrote:
>>>>
>>>> In BSD-land, the system libraries used weak references to solve this --
>>>> they'd provide the symbol, but allow you to provide your own which won,
>>>> and their declaration was behind feature tests. So, for instance, old
>>>> BSD libc had a symbol "end", but you could write a program using your
>>>> own and theirs didn't matter. ("end" was at the end of a block of memory,
>>>> of course.)
>>>
>>> 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.

>
> 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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      08-31-2010
On 2010-08-31, Malcolm McLean <(E-Mail Removed)> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-31-2010
Keith Thompson <(E-Mail Removed)> writes:

> Ian Collins <(E-Mail Removed)> writes:
>> On 08/31/10 11:34 PM, Ben Bacarisse wrote:
>>> Ian Collins<(E-Mail Removed)> writes:
>>>> On 08/31/10 07:38 PM, Seebs wrote:
>>>>>
>>>>> In BSD-land, the system libraries used weak references to solve this --
>>>>> they'd provide the symbol, but allow you to provide your own which won,
>>>>> and their declaration was behind feature tests. So, for instance, old
>>>>> BSD libc had a symbol "end", but you could write a program using your
>>>>> own and theirs didn't matter. ("end" was at the end of a block of memory,
>>>>> of course.)
>>>>
>>>> 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.

>>
>> 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.


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.

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-01-2010
Ben Bacarisse <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:

[...]
>> 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.


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
%

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-01-2010
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:

<snip>
>>> On Ubuntu 9.04, gcc 4.3.3, libc6 and libc6-dev 2.9-4ubuntu6.2

<snip>
> 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.

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-01-2010
Ben Bacarisse <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> Ben Bacarisse <(E-Mail Removed)> writes:
>>> Keith Thompson <(E-Mail Removed)> writes:

> <snip>
>>>> On Ubuntu 9.04, gcc 4.3.3, libc6 and libc6-dev 2.9-4ubuntu6.2

> <snip>
>> 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.


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).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
I do ping others and viceversa but, cannot ping myself jorgeantibes Wireless Networking 0 05-15-2009 11:37 AM
VRRP : I am unable to ping the virtual address, I can only ping thebackup addresses. ATM Cisco 2 11-13-2008 09:50 PM
Can Ping Switch but Can't Ping Rtr (behind it) Bob Simon Cisco 8 01-19-2005 05:31 PM
ping ping Why gruffydd Computer Support 3 12-29-2004 05:09 PM
Can not ping myself, but can ping others =?Utf-8?B?V0pQQw==?= Wireless Networking 6 12-26-2004 05:56 AM



Advertisments