Ping E Sossman

[Martin Lukes]

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

 

[Seebs]

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

 

[Eric Sosman]

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!

 

[Malcolm McLean]

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.

 

[Martin Lukes]

(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

 

[Martin Lukes]

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

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

 

[Keith Thompson]

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.

[...]

 

[Seebs]

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

 

[Peter Nilsson]

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?

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?

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

 

[Eric Sosman]

I was thinking of CPAX.co.uk


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]

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.


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.

Well, I dunno. The problem, ultimately, has no bulletproof
solution absent some kind of central registry of names or particles
of names. If two programmers Sosman and Seebach independently invent
wonderful (but wholly dissimilar) functions and call them wonderful(),
them's the breaks. Even if they call them S_wonderful(), the breaks
remain broken. The person integrating C code from different sources[*]
must always expect name clashes at some level.

[*] By which I mean "wellsprings" or "origins," not "files full of
code." Given the latter and a good set of tools, clashes can be
resolved, perhaps with liberal use of #define.

Besides: Your assessment makes *me* just as guilty as glibc! And
you can't expect me to go along with *that*, can you? ;-)

 

[Eric Sosman]

Er, what?

Sarcasm, that's what. With a serious point about name clashes
lurking in the background. (You might want to look very carefully
at the offered names; they were chosen with some deviousness.)

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


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.


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.

No, quite the opposite. I hope you find my little function
useful (after a suitable name change), and I am sincerely interested
in any suggestions you may have about how it might be improved. I've
appointed myself the final arbiter of which suggestions to ignore and
which to take to heart, of course, but I truly welcome any constructive
criticism and always say "Thank you" to bug reports.

As for maintenance: The code is in no sense a product, and is in
no sense supported. IIRC, it was originally offered under the "Everyone
writes one of these eventually" license, just as an example of what one
particular Everyone had done. There have been some valid criticisms of
the design (mainly, that it violates the "but not simpler" part of
Einstein's famous advice), and I've reflected a bit on whether my love
of simple interfaces mightn't be, well, simplistic. Still, the code
is what it is -- and it's yours to play with. Freer even than Open
Source, it's Dumped Source: have at it!

 

[James Dow Allen]

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

Mr. Sosman, a very valuable member of the C community, has made
the code available *with easily-altered source code* and DID
THIS ALL FOR FREE !! And you're still complaining? Wow.

When you consider that changing the name of this function
*WOULD IMMEDIATELY BREAK* all instances of its use, one can
see why Mr. Sosman is reluctant to leap into this "bug fix."

The Central Registry of Identifier Prefixes might be a good
idea, but it's probably much too late for that.

The namespace arrogance that startled me most was <math.h>'s
awarding j0, j1, etc. all to itself....

James Dow Allen

 

[Alan Curry]

The namespace arrogance that startled me most was <math.h>'s
awarding j0, j1, etc. all to itself....

Yeah that's pretty annoying. y0 and y1 are the ones I collide with often. I
can't use plain and simple names for a set of coordinates for 2 points:

int x0, y0, x1, y1;

All because it was decided that I should rather have convenient access
index to "Bessel functions of the second kind". Now I'm pretty sure that "the
second kind" means you met the aliens but you didn't get probed. And Bessel
is of course the Stooge who invented the vacuum cleaner. None of that seems
worthy of a 2-character global identifier.

Another bad one is the string.h declaration of "index", an old-timey synonym
for strchr that still lingers in some modern contexts.

 

[Seebs]

Another bad one is the string.h declaration of "index", an old-timey synonym
for strchr that still lingers in some modern contexts.

At least that one's not mandated by the spec.

-s

 

[Malcolm McLean]

     No, quite the opposite.  I hope you find my little function
useful (after a suitable name change), and I am sincerely interested
in any suggestions you may have about how it might be improved.  I've
appointed myself the final arbiter of which suggestions to ignore and
which to take to heart, of course, but I truly welcome any constructive
criticism and always say "Thank you" to bug reports.

Breaking under gcc is a major nuisance. 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.

Why not call it getaline() ?

 

[Seebs]

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

Anyway, I guess, I don't really consider it all that "recognized". It's a
fairly new addition to glibc (I'm pretty sure it was added since 2.8), and
only that one library has it, and I think it's optional there.

Frankly, though, this kind of thing disimpresses me with whoever thought it
was an okay thing to check in to a production library.

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?

-s

 

[Ian Collins]

Not gcc. glibc.


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.

 

[Malcolm McLean]

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.

 

[Ian Collins]

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.

That is something of a slur on those of us who have commitments beyond
our work.