UNIX, C, Perl

[Pilcrow]

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C? Examples:
Network and internet access, access to UNIX interprocess controls and
communication, locale determination, EBCDIC/ASCII discrimination, etc.

Almost all of these are easy in Perl. Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these? Isn't
anyone working on this problem? or is it all being left for proprietary
systems?

[Richard Heathfield]

jacob navia said:

Ben Bacarisse wrote:

<snip>

>Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers.

I don't think you're in a position to insist, are you? Not even Microsoft
is in a position to insist on a change to the C language. In fact, not
even Dennis Ritchie is in that position.

It is sometimes difficult to remember that what one person sees as an
obvious improvement, another person sees as a hideous wart. Putting
oneself in another person's position is a useful and informative
intellectual exercise. Think up a change to C that you would really NOT
like to see in the language, and you should get the idea.

By the way, I'm not particularly against the idea of introducing operator
overloading into C (although many people probably are). But politicking
about it in comp.lang.c isn't going to get you anywhere. It's the ISO
people, not us, that you have to convince, and they are going to take a
lot of convincing after the drubbing they took over C99.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

>Ben Bacarisse wrote:

<snip>

>>Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatibl e with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers.

I don't think you're in a position to insist, are you? Not even Microsoft
is in a position to insist on a change to the C language. In fact, not
even Dennis Ritchie is in that position.

I know your position. Let's do nothing, and leave C to die a
peaceful death.

Any language that refuses to change anything and still tries
to see the world as we were in the times of the PDP 11 will
die, and C is going into that direction.

There is NO other solution that to introduce a way to share
libraries using lists/ flexible arrays, what have you in
a simple at the same time general way!

If we use the '[' and ']' notation for that, C libraries can
implement any container they like behind the scenes, the
user of those libraries writes

data[2]

and that is all there is to it!

The library has defined data as a flexible array, a list,
or a simple array and that will work with user code unchanged.

It is sometimes difficult to remember that what one person sees as an
obvious improvement, another person sees as a hideous wart. Putting
oneself in another person's position is a useful and informative
intellectual exercise. Think up a change to C that you would really NOT
like to see in the language, and you should get the idea.

How would *you* solve the above problem?

Obviously you just do NOT want to solve it, and leave the problem
untouched. That way, C libraries can't share any general containers,
and newcomers are put off by needing to code a linked list for the
thousandth time.

By the way, I'm not particularly against the idea of introducing operator
overloading into C (although many people probably are).

Until now you have always attacked me because I dared not only to
say

"I am not against it"

but proposed a concrete implementation to do exactly that.

But politicking
about it in comp.lang.c isn't going to get you anywhere.

I am trying to convince people that what I am proposing is a better
alternative. Why should I stay away from a discussion here?

It's the ISO
people, not us, that you have to convince, and they are going to take a
lot of convincing after the drubbing they took over C99.

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c. Any time I have proposed there
to change anything like even get rid of a buffer overflow in asctime()
the negative reaction of those people was almost unanimous.

For instance I proposed to get rid of trigraphs. Just read that
discussion.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

jacob navia <ja***@nospam.c omwrites:

Richard Heathfield wrote:

>jacob navia said:

>>Ben Bacarisse wrote:

<snip>

>>>Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatib le with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.
That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers.

I don't think you're in a position to insist, are you? Not even
Microsoft is in a position to insist on a change to the C
language. In fact, not even Dennis Ritchie is in that position.

I know your position. Let's do nothing, and leave C to die a
peaceful death.

Your gross misrepresentati ons of other people's opinions are really
getting old. It's possible to disagree with people without being
hostile, but you don't seem to have the knack.

To be clear, your silly parody, "Let's do nothing, and leave C to die
a peaceful death", does not resemble anything Richard has ever written
as far as I know.

[...]

They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.

I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

Any time I have proposed there
to change anything like even get rid of a buffer overflow in asctime()
the negative reaction of those people was almost unanimous.

In that discussion, there were several concrete proposals to change
the specification of asctime.

Most of the negative reactions were in response to your stubborn
refusal to acknowledge that your proposal would change the behavior of
asctime in circumstances where that behavior is now unambiguously (but
strangely) defined. I said, several time, that I'd be willing to
accept your proposal *if* that fact were acknowledged (not that I have
any say in the matter), but you wouldn't compromise even that much.

And for the Nth time, the problem with asctime isn't that it's
possible to trigger a buffer overflow by using it incorrectly, it's
that the conditions under which that buffer overflow is triggered are
not stated clearly enough. strcpy can trigger a buffer overflow just
as easily as asctime can.

For instance I proposed to get rid of trigraphs. Just read that
discussion.

I did read it. Concrete examples were presented of systems on which
trigraphs are still in use. And it was pointed out that the problems
that can be caused by accidental trigraphs are rare, and can be
addressed by issuing warnings when their use might be accidental.

I wouldn't oppose dropping trigraphs from the language, but again,
such a change would alter the behavior of some programs whose behavior
is now unambiguously defined. And if a new C2008 standard were issued
tomorrow, identical to C99 but with trigraphs eliminated, programmers
would still have to deal with the possibility that their code might be
used with older compilers that still support trigraphs.

As long as you refuse to acknowledge the importance of backward
compatibility, even in cases that *you* think are unimportant, it will
be difficult to take your proposals seriously.

If I had as many smart people disagreeing with me as you do, I'd start
to consider very seriously the possibility that I might be wrong.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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"

[Flash Gordon]

Ben Bacarisse wrote, On 03/09/08 17:31:

<snip>

But there *is* an important issue here. Perl's modules work well
together because of the dynamic type system, and the fact that Perl
has very flexible containers. Using C, you may be able to find a
great XML parsing library (for example) but it will probably represent
its lists and tables using different types (and access functions) to
all the other libraries you need. This is why Perl is so good at
"gluing" tasks.

Hmm. I had no major problems stitching together an XML processing
library (and the xslt and xmlsec libraries built on top of it) and
libraries for communicating over the internet in various forms, and
custom in-house libraries that still use their own customer data
structures. All of this in C (plus networking extensions obviously). You
just have to pick the right libraries.

This is the elephant in the room as far as C is concerned. Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatible with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.

Sometimes it is, sometimes it is hard. Sometimes stitching things
together in Perl is a right pain.
--
Flash Gordon

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>jacob navia said:

>>Ben Bacarisse wrote:

<snip>

>>>Because
there is no agreed way to program a flexible array, a list or a map,
everyone writes their own, or uses a published one that is
incompatib le with all the other published ones out there. It is often
a lot of work just to coax two libraries to work together.
That is why I have been insisting that we adopt the operator
overloading feature that would allow using the '[' and ']' notation for
general containers.

I don't think you're in a position to insist, are you? Not even
Microsoft is in a position to insist on a change to the C language. In
fact, not even Dennis Ritchie is in that position.

I know your position. Let's do nothing, and leave C to die a
peaceful death.

Well, no, that isn't my position. But it seems you have misunderstood the
point I was making, and I have no particular desire to explain the
blindingly obvious twice over.

<snip>

>By the way, I'm not particularly against the idea of introducing
operator overloading into C (although many people probably are).

Until now you have always attacked me because I dared not only to
say

"I am not against it"

but proposed a concrete implementation to do exactly that.

No, I would not be so foolish as to attack you for daring to propose a
change to the C language. I'm just curious as to why you propose it here,
since nobody here has any authority to change the language definition
(except Larry, perhaps, since he's actually a voting member of the ISO C
Committee). It seems rather pointless.

>But politicking
about it in comp.lang.c isn't going to get you anywhere.

I am trying to convince people that what I am proposing is a better
alternative.

Fine. Why not go convince the ducks in St James's Park? (Serious question,
and if you answer it seriously, the answer will reveal a serious point.)

Why should I stay away from a discussion here?

Why should you stay away from a discussion with the ducks in St James's
Park?

>It's the ISO
people, not us, that you have to convince, and they are going to take a
lot of convincing after the drubbing they took over C99.

They will never do anything

If you think so, then you're sunk, because they're the only ones who /can/
do anything.

since their main objective is to preserve
C as a language that should run legacy code with no new development,

So you claim.

as Mr Gwyn explained in comp.std.c.

Cite, please. You're so completely useless at understanding what people say
that I want to see some evidence before I'll even think about believing
that claim.

Any time I have proposed there
to change anything like even get rid of a buffer overflow in asctime()
the negative reaction of those people was almost unanimous.

I can think of several reasons for that, none of which does you any credit,
so I'll keep them to myself.

For instance I proposed to get rid of trigraphs.

....and just abandon platforms with limited character sets. Nice one.

Just read that discussion.

What's the point? It'll just be same ol' same ol'. I've read your
"discussion s" before, the ones where you call people idiots and liars for
daring to have a viewpoint different from yours. No, thanks.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

Richard Heathfield wrote:

[snip]

I asked you a question Heathfield, a question that you conveniently
snipped away.

I repeat it:
How would *you* solve the above problem?

How would you make different libraries interoperate with lists,
flexible arrays, arrays, double linked lists, etc?

If I use a networking library I get a list of servers
from a dns request. I need the list package of the
net library.

If I use in the same program a file handling library I get
a list of files from a request like
"*.c"

Both lists packages will be redundant code and name clashes are
highly probable

How would *you* solve this problem?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@nospam.c omwrites:

[...]

>They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.

I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:

Can we get rid of gets()?

Mr Gwyn defended keeping gets() in the standard document.

And he won. gets() is still in the C99 document.

I started a similar discussion last year, 11 years later and Mr Gwyn
was again in the group of the ultra-conservatives that want to keep
gets(), trigraphs, and vehemently deny that ANY changes should
be done.

He repeated the same position in 2004, when I started again a discussion
about gets().

And in 2007 he repeated his position. No changes, gets belong to the
language.

The same for ALL the proposals to change a minimal part of the
language. Not even blatant errors like trigraphs.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

jacob navia wrote:

Keith Thompson wrote:

>jacob navia <ja***@nospam.c omwrites:

[...]

>>They will never do anything since their main objective is to preserve
C as a language that should run legacy code with no new development,
as Mr Gwyn explained in comp.std.c.

I don't recall Doug Gwyn ever saying that, and I'm certainly not going
to take your word for it. Please post the Message-ID of an article in
which he said that.

The 26 september 1997, Dennis Yelle had the idea of asking in comp.std.c:

Can we get rid of gets()?

Mr Gwyn defended keeping gets() in the standard document.

And he won. gets() is still in the C99 document.

I started a similar discussion last year, 11 years later and Mr Gwyn
was again in the group of the ultra-conservatives that want to keep
gets(), trigraphs, and vehemently deny that ANY changes should
be done.

He repeated the same position in 2004, when I started again a discussion
about gets().

And in 2007 he repeated his position. No changes, gets belong to the
language.

The same for ALL the proposals to change a minimal part of the
language. Not even blatant errors like trigraphs.

The fact that Doug Gwyn opposes one proposed change to C
does not demonstrate that he opposes or would oppose all changes.
The fact that one prime number is even does not demonstrate that
all prime numbers are even.

Even if Doug Gwyn opposed all changes, it would not follow
that he wants "to preserve C as a language that should run legacy
code with no new development." The fact that all prime numbers are
even does not mean that they are all blue.

Also, loaded terms like "ultra-conservatives," "vehemently ,"
and "blatant" do not make your argument stronger, just hotter. Or
to put it differently: Your childish and irresponsible use of loaded
terms like "ultra-conservatives," "vehemently ," and "blatant" do not
make your pathetic excuse for an argument stronger, just hotter,
louder, and even MORE ridiculous than usual.

--
Er*********@sun .com

[Kenny McCormack]

In article <1220469839.903 758@news1nwk>,
Eric Sosman <Er*********@su n.combloviated:
....

Also, loaded terms like "ultra-conservatives," "vehemently ,"
and "blatant" do not make your argument stronger, just hotter. Or
to put it differently: Your childish and irresponsible use of loaded
terms like "ultra-conservatives," "vehemently ," and "blatant" do not
make your pathetic excuse for an argument stronger, just hotter,
louder, and even MORE ridiculous than usual.

Calm down. Take your medicine. You'll feel better soon.

[jacob navia]

Kenny McCormack wrote:

Calm down. Take your medicine. You'll feel better soon.

Kenny, you did not answer my post...

You consider C really dead?

I mean your opinion *is* important (at least to me)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32