«

Hi

I have been trying to use a utility called getline by E Sossman,
distributed on the website for the comp/lang/c forum. My code would not
compile, I eventually worked out the strange error messages and the
problem is that there is already a function in glibc called getline.

I would advise renaming this function in a future version to avoid this
clash. Unfortunately C doesn't have proper support for namespaces but you
can use a prefix instead, eg rename the function ES_getline and all other
globally exported symbols could also start ES_.

Cheers
Martin

On 2010-08-29, Martin Lukes <> wrote:
> I have been trying to use a utility called getline by E Sossman,
> distributed on the website for the comp/lang/c forum.

There is no such thing as "the website for the comp/lang/c forum". This
is a newsgroup, and there is no specific website for it.

> My code would not
> compile, I eventually worked out the strange error messages and the
> problem is that there is already a function in glibc called getline.

This is a fairly common problem. It is, IMHO, 100% glibc's fault --
the name was fairly widely used before they added theirs, and I can't
see any reason for which they couldn't have picked another name.

I suspect that, as a matter of practicality, a lot of people will now
have to rename their perfectly reasonable "getline()" functions to
make up for glibc's high-handed attitude towards namespaces.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
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.

On 8/29/2010 3:10 PM, Martin Lukes wrote:
> Hi
>
> I have been trying to use a utility called getline by E Sossman,
> distributed on the website for the comp/lang/c forum. My code would not
> compile, I eventually worked out the strange error messages and the
> problem is that there is already a function in glibc called getline.
>
> I would advise renaming this function in a future version to avoid this
> clash. Unfortunately C doesn't have proper support for namespaces but you
> can use a prefix instead, eg rename the function ES_getline and all other
> globally exported symbols could also start ES_.

(1) I'll rename the function to ma11oc(), or maybe longjump().

(2) As the TBV (Time Between Versions) is lengthy and erratic,
it may be some time before the change percolates to you. In the
meanwhile, you're free to edit your own copy of the source yourself.

(3) I respond more favorably to pings when they spell my name
the way my parents did.

(4) Thanks for the feedback!

--
Eric Sosman
lid

On Aug 29, 10:10*pm, Martin Lukes <nos...@nospam.com> wrote:
> Unfortunately C doesn't have proper support for namespaces but you
> can use a prefix instead, eg rename the function ES_getline and all other
> globally exported symbols could also start ES_.
>
Then code rapidly becomes unreadable. We don't really care that
someone with the initials ES coded the function. The purpose of
getline() is clear, ES_getline() could mean anything.

Eric Sosman writes:
> (1) I'll rename the function to ma11oc(), or maybe longjump().

Er, what?

> (2) As the TBV (Time Between Versions) is lengthy and erratic,
> it may be some time before the change percolates to you. In the
> meanwhile, you're free to edit your own copy of the source yourself.

It's sad when people create software and then can't be bothered to
maintain it. It's not a big change.

> (3) I respond more favorably to pings when they spell my name
> the way my parents did.

Sorry for the miss-spelling. I've encountered a couple of Sossman's in my
time (and one Sussman) but never a Sosman until now.

> (4) Thanks for the feedback!

Your welcome, except that from your sarcastic reply I suspect that you
aren't greatful for bug reports in the slightest. Next time I don't think
I'll bother.

Cheers,
Martin

Seebs writes:
> There is no such thing as "the website for the comp/lang/c forum". This
> is a newsgroup, and there is no specific website for it.

I was thinking of CPAX.co.uk

>> My code would not
>> compile, I eventually worked out the strange error messages and the
>> problem is that there is already a function in glibc called getline.
>
> This is a fairly common problem. It is, IMHO, 100% glibc's fault -- the
> name was fairly widely used before they added theirs, and I can't see
> any reason for which they couldn't have picked another name.
>
> I suspect that, as a matter of practicality, a lot of people will now
> have to rename their perfectly reasonable "getline()" functions to make
> up for glibc's high-handed attitude towards namespaces.

No, as I tried to explain it is C itself (not just glibc) that provides
a single global namespace. Emulating namespaces with prefixes like ES_ is
the only solution to this.

Cheers,
Martin

Martin Lukes <> writes:
> Seebs writes:
>> There is no such thing as "the website for the comp/lang/c forum". This
>> is a newsgroup, and there is no specific website for it.
>
> I was thinking of CPAX.co.uk

If you mean cpax.org.uk, there's some good stuff there, but it
is in no way "the" web site for the comp.lang.c (not comp/lang/c)
newsgroup.

The comp.lang.c FAQ is at <http://www.c-faq.com>.

<http://clc-wiki.net/> describes itself as "an offshoot of the
comp.lang.c newsgroup".

Unmoderated newsgroups in general are sufficiently chaotic that
it's not really possible to have any kind of official web site for
a newsgroup.

[...]

--
Keith Thompson (The_Other_Keith) kst- <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"

On 2010-08-30, Martin Lukes <> wrote:
> No, as I tried to explain it is C itself (not just glibc) that provides
> a single global namespace.

Which is why C itself is careful to reserve implementation namespace for
future expansion, and tries to avoid picking names that are widely used.

And why glibc was Just Plain Wrong to pick a name which was already in
VERY widespread usage as a program-internal name and make it a library
feature name.

> Emulating namespaces with prefixes like ES_ is
> the only solution to this.

But it would be sufficient, in many cases, for library maintainers not to
go out of their way to pick commonly-used names for their idiosyncratic
extensions.

Extensions like that are a much worse solution than the very occasional
namespace clashes; they make it hard for people to read code clearly.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
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.

Martin Lukes <nos...@nospam.com> wrote:
> Eric Sosman writes:
> > * * *(1) I'll rename the function to ma11oc(), or maybe
> > longjump().
>
> Er, what?

There's nothing wrong with the name getline. It describes
the function well and doesn't class with any implementation
namespace. Why rename it to something inappropriate?

> > * * *(2) As the TBV (Time Between Versions) is lengthy
> > and erratic, it may be some time before the change
> > percolates to you. *In the meanwhile, you're free to
> > edit your own copy of the source yourself.
>
> It's sad when people create software and then can't be
> bothered to maintain it.

What's to maintain?

> It's not a big change.

What's to change?

<snip>
> > * * *(4) Thanks for the feedback!
>
> Your welcome, except that from your sarcastic reply I
> suspect that you aren't greatful for bug reports in the
> slightest.

Since you haven't described a bug in his code, it's hard
to see why he should do much of anything about it.

> Next time I don't think I'll bother.

Obviously they are rare a far between, but Eric has always
been greatful for error reports in his code. If you find
a genuine one, I'm sure he'll be appreciative. As for getline
though, it's a somewhat simple function that has been written
in many different ways and many different people. Most people
roll their own in 10 mins. I'm sure Eric has much bigger fish
to fry.

Regarding your original suggestion...

I would advise renaming this function in a future version
to avoid this clash.

The problem seems to be a link ordering for glibc.

Unfortunately C doesn't have proper support for namespaces
but you can use a prefix instead, eg rename the function
ES_getline and all other globally exported symbols could
also start ES_.

Which wouldn't be the wisest of choices since E followed by
a number or capital letter is reserved for use by <errno.h>.

--
Peter

On 8/30/2010 3:30 PM, Martin Lukes wrote:
> Seebs writes:
>> There is no such thing as "the website for the comp/lang/c forum". This
>> is a newsgroup, and there is no specific website for it.
>
> I was thinking of CPAX.co.uk
>
>>> My code would not
>>> compile, I eventually worked out the strange error messages and the
>>> problem is that there is already a function in glibc called getline.
>>
>> This is a fairly common problem. It is, IMHO, 100% glibc's fault -- the
>> name was fairly widely used before they added theirs, and I can't see
>> any reason for which they couldn't have picked another name.
>>
>> I suspect that, as a matter of practicality, a lot of people will now
>> have to rename their perfectly reasonable "getline()" functions to make
>> up for glibc's high-handed attitude towards namespaces.
>
> No, as I tried to explain it is C itself (not just glibc) that provides
> a single global namespace. Emulating namespaces with prefixes like ES_ is
> the only solution to this.

... except that it's not a solution. The code written by
Edwin Schermerhorn, Elias Spottbinder, Ellen Sperling, Emilia
Sofasitter, and even Evertasty Succotash, Inc. will clash with mine.

Or, turn your suggestion around: Why complain to me, when the
problem is that glibc's getline() isn't named glibc_getline()?

--
Eric Sosman
lid