UNIX, C, Perl

Bill Reid wrote:
....

IN WASHINGTON!!! (or whever the "C" standards committee met,

As you might expect for an international standards organization, the
meetings of ISO/IEC JTC1/SC22/WG14 are held in a wide variety of
places around the world. Judging from
<http://www.open-std.org/jtc1/sc22/wg14/www/meetings>, it would appear
that they have not met in Washington at any time since at least 1994,
and probably earlier. Since the US member is INCITS J11
<http://www.ncits.org/tc_home/j11.htm>, and that committee's meetings
are co-located with those of WG14, it doesn't look like Washington has
anything to do with this.

Sep 2 '08 #7

Antoninus Twink

On 2 Sep 2008 at 11:48, Pilcrow wrote:

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.

You've spent too much time being brainwashed by the clc regulars.

ALL of these things are possible in C, OF COURSE. And if Official
Standards (peace be upon them) are really important to you, there's this
one you might have heard of: POSIX.

Sep 2 '08 #8

Keith Thompson

Pilcrow <pi*****@pp.infowrites:

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?

It depends on what you mean by "ordinary C".

The C language is defined by an ISO standard. (Actually by two
versions of the same ISO standard, since the most recent one has not
yet been widely implemented.) That standard specifically permits
extensions with certain limitations -- and many implementations
provide extensions without those limitations in a non-conforming mode.

If you want to write code that depends only on features defined in the
language standard, then your code will be portable to any conforming C
implementation -- but it won't be able to do networking, interprocess
communication, and so forth.

If you need to use such features, you can. You'll just have to use
some extension (such as POSIX) that's provided by your implementation.
Your program won't be portable to an implementation that doesn't
provide the particular extension(s) you're depending on, and in many
cases your program's behavior won't be defined by the language
standard.

This kind of tradeoff is unavoidable.

C is *designed* to allow writing non-portable code.

The thing is, though, that for most of the extensions you might want
to use, this newsgroup isn't the best place to discuss them. If you
want to ask how to use POSIX, there's comp.unix.programmer; for Win32,
there's comp.os.ms-windows.programmer.win32.

Don't confuse the scope of this newsgroup (as agreed upon by most of
the participants) with the scope of C programming.

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

Sep 2 '08 #9

Pilcrow

On Tue, 02 Sep 2008 12:04:38 GMT, James Kuyper <ja*********@verizon.net>
wrote:

>Pilcrow wrote:
>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, ...

They are not impossible in "ordinary C", they are impossible in strictly
conforming C. The C that operating systems are written in will make
heavy use of highly non-portable constructs that give access to all of
these things. In some cases, those non-portable constructs will consist
of calls to routines written in assembly language, or in-line assembly
language, but a very large fraction of the system can be written
entirely in non-portable C.

>... locale determination, EBCDIC/ASCII discrimination, etc.

I'm not at all clear to me why you think that those can't be performed
in ordinary C. What features are you asking for that aren't provided by
<locale.h>? Perhaps if you described in more detail the desired
functionality I could address the question better.

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

There are such mechanisms - they are called "header files" and
"libraries", and together they serve a very similar purpose.

>... Isn't
anyone working on this problem? or is it all being left for proprietary
systems?

There's no reasons why the libraries have to be proprietary, though many
certainly are.

I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.

Sep 2 '08 #10

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgmeant to say:
....

>Don't confuse the scope of this newsgroup (as defined by a small, but
very vocal subset, of the participants) with the scope of C programming.

Typos fixed. No thanks are necessary. HTH. HAND.

Sep 2 '08 #11

Eric Sosman

Pilcrow wrote:

[...] But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

Good: Problem solved, need satisfied, it's Miller Time.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will
you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
Or to put it another way: If you feel impelled to throw out your
working Perl solution and write a fresh one in C, what is it
about Perl that you find unsatisfactory?

I'm not familiar with the libraries you mention, but there
are plenty of C libraries out there, perhaps including a few that
perform the kinds of tasks you're interested in.

I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.

I suspect you'll find that it's written in a C dialect --
maybe strictly-conforming C, maybe something looser -- and that
it also makes use of libraries of various kinds that are in turn
written in Lordknowswhat. Perhaps all you're really looking for
is the packaging of a bunch of libraries into a single convenient
framework so you don't have to hunt them up and integrate them?
That's a perfectly reasonable thing to want, but ... as part of
the definition of a general-purpose language?

In your kitchen, I imagine you have an assortment of various
knives. You've probably got a few general-purpose knives, and a
few that are more specialized: heavy broad-bladed knives for chopping,
skinny flexible-bladed knives for filleting, knives with serrated
edges for slicing bread, knives with finer serrations for cutting
tomatoes ... Why do you have so many knives, instead of doing all
your cutting, slicing, and chopping with just one? Is it, perhaps,
because a knife that could handle *all* cutting tasks might have
usability problems?

Stretching the analogy right up to the breaking point, here
are two competing views of what C should be:

http://www.victorinox.com/index.cfm?...age=158&lang=D

http://www.thinkgeek.com/gadgets/tools/8b97/zoom/

You'll notice that they differ mostly in degree.

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

Sep 2 '08 #12

Eric Sosman wrote:

Pilcrow wrote:
[...] But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

Good: Problem solved, need satisfied, it's Miller Time.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

This isn't about a particular problem and it's solution, it's about
the availability of problem-solving tools. He's asking how he could
have used a similar approach to solving the problem in the first
place, if he had chosen C rather than perl.

Sep 2 '08 #13

Pilcrow wrote:
....

I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many
similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.

Sep 2 '08 #14

Ian Collins

Pilcrow wrote:

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?

Where the facilities exist, the C libraries are provided. What do you
think Perl modules use?

--
Ian Collins.

Sep 2 '08 #15

In article <db**********************************@73g2000hsx.g ooglegroups.com>,
<ja*********@verizon.netwrote:
....
(ditzy Eric scribbled)

> One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

This isn't about a particular problem and it's solution, it's about
the availability of problem-solving tools. He's asking how he could
have used a similar approach to solving the problem in the first
place, if he had chosen C rather than perl.

Yes. Anyone with a couple of brain cells to rub together can see that.

But it doesn't fit in with the CLC regs approach.

Go back and re-read Eric's text. It is chock full of nasty sarcasm
aimed at belittling the OP, while clearly feigning ignorance of what
this thread is really about.

Sep 2 '08 #16

Richard

Eric Sosman <Er*********@sun.comwrites:

Pilcrow wrote:
>[...] But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

Good: Problem solved, need satisfied, it's Miller Time.

>How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

Yes. I mean, who on earth EVER prototypes something in a high level
language and then moves to something like C for, oh, I dont know,
speed, memory usage etc. Are you always so ready to belittle people?

you then go on to solve it in Ada, Fortran, Lisp, Jovial, ...?
Or to put it another way: If you feel impelled to throw out your
working Perl solution and write a fresh one in C, what is it
about Perl that you find unsatisfactory?

I'm not familiar with the libraries you mention, but there
are plenty of C libraries out there, perhaps including a few that
perform the kinds of tasks you're interested in.

So you do not know. Just throw in a bit of sarcasm because you are
bored?

>
>I am sure that it is possible, since Perl itself is written in standard
C, or at least GCC.

I suspect you'll find that it's written in a C dialect --
maybe strictly-conforming C, maybe something looser -- and that
it also makes use of libraries of various kinds that are in turn
written in Lordknowswhat. Perhaps all you're really looking for
is the packaging of a bunch of libraries into a single convenient
framework so you don't have to hunt them up and integrate them?
That's a perfectly reasonable thing to want, but ... as part of
the definition of a general-purpose language?

In your kitchen, I imagine you have an assortment of various
knives. You've probably got a few general-purpose knives, and a
few that are more specialized: heavy broad-bladed knives for chopping,
skinny flexible-bladed knives for filleting, knives with serrated
edges for slicing bread, knives with finer serrations for cutting
tomatoes ... Why do you have so many knives, instead of doing all
your cutting, slicing, and chopping with just one? Is it, perhaps,
because a knife that could handle *all* cutting tasks might have
usability problems?

Who the hell do you think you are second guessing the OP? He came here
for C help - not you strutting around and telling him what he wants.

>
Stretching the analogy right up to the breaking point, here
are two competing views of what C should be:

http://www.victorinox.com/index.cfm?...age=158&lang=D

http://www.thinkgeek.com/gadgets/tools/8b97/zoom/

You'll notice that they differ mostly in degree.

The only thing I noticed is that you made a right fool out of
yourself. Congratulations and another clc stripe.

Sep 2 '08 #17

In article <g9**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....

> Good: Problem solved, need satisfied, it's Miller Time.

>>How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

One first wonders why you feel a need to re-solve a problem
already solved, just for the sheer joy of doing it in C. Will

Yes. I mean, who on earth EVER prototypes something in a high level
language and then moves to something like C for, oh, I dont know,
speed, memory usage etc. Are you always so ready to belittle people?

Answering for Eric: Yes. In a word. Yes. It is my biggest thrill in
life.

Sep 2 '08 #18

Pilcrow

On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), ja*********@verizon.net wrote:

>Pilcrow wrote:
...
>I am certainly glad to hear that these things are possible. But perhaps
an example of what I mean is appropriate. Last year I had a list of
several hundred addresses in the USA for which I wanted the 5+4 postal
zip codes. Using a standard module, 'WWW::Mechanize', from CPAN
<http://en.wikipedia.org/wiki/CPAN>, I was able, in about an hour, to
write a program (or a 'script'), in perl, that would access
<http://zip4.usps.com/zip4/welcome.jsp>, programmatically enter each
address, parse the response, extract the zip codes I needed, and update
my list.

The program I wrote is generalized enough to be able to do the same with
any other similar list. This saved me the chore of manually entering
each address into the form on that web page and copying and pasting the
zip code to my list. That chore would have taken several days, since I
am a clumsy typist, and the list, as I have said, has several hundred
entries.

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many

why do you have to guess? CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).

>similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.

Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible? (I did my trick on a
MS platform, using a distribution of Perl know as 'Strawberry' perl, but
it would have worked also in a UNIX or Linux environment, using Perl
compiled for those). I have made use of Google's code search facility,
but it has its limitations.

Perhaps the reason for this contrast between C and Perl is the
cooperative spirit behind the Open Source movement. Also the evolving
nature of Perl, which, though it dates to 1987, has been frequently
improved and expanded. Facilities for OO programming, multi-threading,
forking, and others, though not in Perl a few years ago, are now
standard. And backward compatability has always been a consideration.

The documentation for Perl is also exemplary. There is little need to go
beyond the documentation available at the command line. All the
documentation needed is included with the installation. Little need to
buy other texts. I admit that more documentation is needed than with C,
but perl is a more complex language.

Sep 2 '08 #19

Pilcrow wrote:

On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), ja*********@verizon.net wrote:

Pilcrow wrote:

....

How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?
There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many

why do you have to guess? ...

Because I don't possess enough information to be certain, one way or
the other. Do you? If your question was just rheotorical, as now seems
to be the case, then all you're doing is trolling this newsgroup to
promote perl as a superior alternative to C. I know too much about
perl to fall for that one: perl has a number of advantages over C in
particular contexts, and i use it routinely when those contexts apply,
but it has nowhere near enough advantages to replace C in all
contexts. I wouldn't dream of using it for any of the tasks that I
currently use C for.

... CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).

I can't figure out what relevance that has to my guesswork. It almost
seems as if you're saying that a C repository cannot count as
"similar" unless access to that repository is automatically installed
when you install your C compiler; but I can't imagine that you're
making such a fatuous suggestion.

similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.

Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible?

The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

Sep 2 '08 #20

Pilcrow

On Tue, 02 Sep 2008 04:48:57 -0700, Pilcrow <pi*****@pp.infowrote:

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

So many people have accused me of having a hidden agenda that I feel I
should declare my agenda explicitly. I am a man who has had a bit of
programming experience, most recently with Perl, who is now trying to
acquire a working knowledge of C, sufficient to do the kinds of things I
am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, especially as to the resources available to
the C programmer who is trying not to have to reinvent the wheel, but I
seem to have ruffled some feathers, for which I apologize. Please bear
with me, and be patient.

I already have gotten some answers, such as the existence of the
locale.h header file, which I should have noticed before.

I again apologize to all of you, but C, though faster than Perl, seems
to me very constricting. I am still working my way through K&R2, (and
posting some of my solutions on clc-wiki), so maybe there will be an
epiphany soon. I hope so.

Sep 3 '08 #21

Pilcrow

On Tue, 2 Sep 2008 16:13:34 -0700 (PDT), ja*********@verizon.net wrote:

>Pilcrow wrote:
>On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), ja*********@verizon.net wrote:

>Pilcrow wrote:

...

>How could I do the same sort of thing using C? Is there a repository of
libraries for C, similar to CPAN for Perl? If not, is anyone working on
it?

There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many

why do you have to guess? ...

Because I don't possess enough information to be certain, one way or
the other. Do you? If your question was just rheotorical, as now seems
to be the case, then all you're doing is trolling this newsgroup to
promote perl as a superior alternative to C. I know too much about
perl to fall for that one: perl has a number of advantages over C in
particular contexts, and i use it routinely when those contexts apply,
but it has nowhere near enough advantages to replace C in all
contexts. I wouldn't dream of using it for any of the tasks that I
currently use C for.

>... CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included (unless you're installing ActiveState Perl, and a
similar facility is provided there).

I can't figure out what relevance that has to my guesswork. It almost
seems as if you're saying that a C repository cannot count as
"similar" unless access to that repository is automatically installed
when you install your C compiler; but I can't imagine that you're
making such a fatuous suggestion.

>similar repositories do exist for C code. What you're asking about is
mostly a social issue having to do with how CPAN works; it isn't
related to any technical differences between C and perl. Personally,
the repository I have the most familiarity with is sourceforge.net,
which handles a lot more than just C libraries.

Similar repositories? How do I search them? Do they include
documentation? Are they cross-platform compatible?

The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

Sep 3 '08 #22

Ron Ford

On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:

>>The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

You're not going to find CPAN here with the unterlanguage. It requires an
ecumenism that doesn't exist for C. Not sure why.

Every time time you "reinvent the wheel," you have to have a caller and a
target. I find that crossing syntax avoids weaknesses in given syntaxes.

Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.
--
What men value in this world is not rights but privileges. 7
H. L. Mencken

Sep 3 '08 #23

Nick Keighley

On 3 Sep, 07:47, Ron Ford <r...@example.invalidwrote:

On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:

>The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

I apologize. *I don't think Perl is superior to C. *Every Perl
programmer, however, knows of the existence of CPAN. *I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN,

C has no equivalent to CPAN. But then CPAN is pretty unique
to perl. You could say it was one of perl's selling points.

so that I don't have to reinvent the wheel with every
new task. *I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

You're not going to find CPAN here with the unterlanguage. *It requiresan
ecumenism that doesn't exist for C. *Not sure why.

Every time time you "reinvent the wheel," you have to have a caller and a
target. *

>I find that crossing syntax avoids weaknesses in given syntaxes.

what does that mean? Is it even english?

Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.

effectivly there is only one perl implementation
--
Nick Keighley

I have found that all ugly things are made by those who strive to make
something beautiful and that all beautiful things are made by those
who
strive to make something useful.
-- Oscar Wilde

Sep 3 '08 #24

Flash Gordon

Pilcrow wrote, On 03/09/08 05:25:

<snip>

I apologize. I don't think Perl is superior to C. Every Perl
programmer, however, knows of the existence of CPAN. I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN, so that I don't have to reinvent the wheel with every
new task. I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

Every Linux distribution comes with shed loads of libraries that are
accessible through C. Every OS provides a number of system specific
libraries for doing certain things (such as networking & graphics if the
system supports them natively, as modern personal computers generally
do). There are commercially available libraries for a number of tasks if
you can pay the money and live with the licensing terms. There are
things like Sourceforge. A number of posters here have their own
libraries they make available. However, there are things which are
fundamentally easier in Perl even if you have C libraries to do the
donkey work for you.

Oh, and modules in CPAN don't always work on all systems to which Perl
has been ported (I had some problems with modules on SCO a few years
back), so C libraries for specific tasks not always being portable to
everywhere is no different.
--
Flash Gordon

Sep 3 '08 #25

Richard Bos

Pilcrow <pi*****@pp.infowrote:

On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), ja*********@verizon.net wrote:

There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many

why do you have to guess? CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included

That's a neat trick, given that I've installed PERL on machines without
internet access.

Richard

Sep 3 '08 #26

Ron Ford

On Wed, 3 Sep 2008 00:23:52 -0700 (PDT), Nick Keighley posted:

On 3 Sep, 07:47, Ron Ford <r...@example.invalidwrote:
>On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:

>>>>The only such repository I'm familiar with is sourceforge.net. If you
check out their web site, it's pretty obvious how to search it.
Documentation seems to be the norm, not the exception, but I'm sure
that the quality of the documentation is highly variable. I'm sure
that cross-platform compatibility is also highly variable. That's
pretty much unavoidable when source code comes from such a wide
variety of sources.

>>I apologize. *I don't think Perl is superior to C. *Every Perl
programmer, however, knows of the existence of CPAN. *I was trying to
find how I could find tested solutions in C, similar to the tested
solutions of CPAN,

C has no equivalent to CPAN. But then CPAN is pretty unique
to perl. You could say it was one of perl's selling points.

Absolutely. The rest of us, eg, c, c++, c sharp, c flat, fortran, fortran
flat and karaoke, best note the strength of perl's syntax.

>

>>so that I don't have to reinvent the wheel with every
new task. *I will try to explore sourceforge more thoroughly, which I
have already used for various utilities.

You're not going to find CPAN here with the unterlanguage. *It requires an
ecumenism that doesn't exist for C. *Not sure why.

Every time time you "reinvent the wheel," you have to have a caller and a
target. *

>>I find that crossing syntax avoids weaknesses in given syntaxes.

what does that mean? Is it even english?

Since texans have monopolized vapidity, I'm afraid the answer is yes. I
can't make the point without posting a syntax which is not c, but that just
reminds me of texans, the not-constitution oil retards.

>

>Now that I think about it, the first reason for the lack of ecumenism is
history and the second is that there are dozens of competing
implementations of C while perl competes more convincingly for a
narrowslice, like sysadmins.

effectivly there is only one perl implementation

Right.
--
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children smart. 5
H. L. Mencken

Sep 3 '08 #27

Ron Ford

On Wed, 03 Sep 2008 08:27:34 GMT, Richard Bos posted:

Pilcrow <pi*****@pp.infowrote:

>On Tue, 2 Sep 2008 12:32:15 -0700 (PDT), ja*********@verizon.net wrote:

>>>There is no single repository for C libraries which plays the same
role for C that CPAN does for perl, but I would guess that many

why do you have to guess? CPAN is so much integrated with Perl, that
whenever Perl is installed, the access to CPAN (cpan.pm) is
automatically included

That's a neat trick, given that I've installed PERL on machines without
internet access.

Richard

..pm brings you farther with perl and a net connection than your installs.
--
Unquestionably, there is progress. The average American now pays out twice
as much in taxes as he formerly got in wages. 1
H. L. Mencken

Sep 3 '08 #28

James Kuyper

Pilcrow wrote:
....

am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, ...

Asking provocative questions tends, by definition, to provoke negative
reactions. I'd recommend asking interesting questions, rather than
provocative ones.

....

I already have gotten some answers, such as the existence of the
locale.h header file, which I should have noticed before.

I didn't realize that you were that unfamiliar with C, and therefore
misunderstood your comments as a dismissal of <locale.has being
insufficiently powerful. It might be insufficiently powerful; C++'s
support for locales, for instance, is much more sophisticated - so much
so that I can't quite figure out how to take advantage of it's powerful
capabilities - so there's certainly room for improvement (in both
languages).

Sep 3 '08 #29

Richard

James Kuyper <ja*********@verizon.netwrites:

Pilcrow wrote:
...
>am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, ...

Asking provocative questions tends, by definition, to provoke negative
reactions. I'd recommend asking interesting questions, rather than
provocative ones.

"Provocative" means interesting. It does not mean it needs an aggressive
reply.

Sep 3 '08 #30

Nick Keighley

On 3 Sep, 11:18, Ron Ford <r...@example.invalidwrote:

On Wed, 3 Sep 2008 00:23:52 -0700 (PDT), Nick Keighley posted:
On 3 Sep, 07:47, Ron Ford <r...@example.invalidwrote:
On Tue, 02 Sep 2008 21:25:09 -0700, Pilcrow posted:

<snip>

Every time time you "reinvent the wheel," you have to have a caller and a
target. *

>I find that crossing syntax avoids weaknesses in given syntaxes.

what does that mean? Is it even english?

Since texans have monopolized vapidity, I'm afraid the answer is yes. *I
can't make the point without posting a syntax which is not c, but that just
reminds me of texans, the not-constitution oil retards.

since this makes no more sense than the bit I tried to get you clarify
I assume you don't actaully want to communicate.

<snip>

--
Nick Keighley

Sep 3 '08 #31

In article <Nduvk.481$Wd.223@trnddc01>,
James Kuyper <ja*********@verizon.netwrote:

>Pilcrow wrote:
...
>am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, ...

Asking provocative questions tends, by definition, to provoke negative
reactions. I'd recommend asking interesting questions, rather than
provocative ones.

This is true on Usenet and is Usenet's primary flaw.

It's not true in general (Note: You should probably spend some time with
a dictionary - look up the word "provocative") - that is, in real life - but
it is true that anything the least bit off the well-trodden path in a
Usenet posting, just gets people's dander up. The thread then just
turns into a big mess of defensiveness.

Sep 3 '08 #32

In article <4h********************************@4ax.com>,
Pilcrow <pi*****@pp.infowrote:
....

>So many people have accused me of having a hidden agenda that I feel I
should declare my agenda explicitly. I am a man who has had a bit of
programming experience, most recently with Perl, who is now trying to
acquire a working knowledge of C, sufficient to do the kinds of things I
am used to doing with Perl. I ask provocative questions in the attempt
of gaining new knowledge, especially as to the resources available to
the C programmer who is trying not to have to reinvent the wheel, but I
seem to have ruffled some feathers, for which I apologize. Please bear
with me, and be patient.

I already have gotten some answers, such as the existence of the
locale.h header file, which I should have noticed before.

I again apologize to all of you, but C, though faster than Perl, seems
to me very constricting. I am still working my way through K&R2, (and
posting some of my solutions on clc-wiki), so maybe there will be an
epiphany soon. I hope so.

Comments:
1) The obvious question is: Why? Others have alluded to this
question as well. The basic fact is that, in the context of
hosted systems, C is a legacy language; I can't see any reason
to do new development in it. People are pretty open about the
fact that, in today's world, C's domain is a) maintaining legacy
code and b) embedded systems.
2) Despite the name, this is not the newsgroup for you. None of the
things that you want to do are "on topic" here. I'm surprised
people haven't been hammering this point a lot harder than they
have. In fact, it can be said that, in general, anything that
you can do in C that is "on topic" here, shouldn't be done in C.
It should be done in a simple scripting language, such as AWK or Perl.

Sep 3 '08 #33

Pilcrow said:

Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

Examples:
Network and internet access,

C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)

access to UNIX interprocess controls and communication,

Unix systems provide this access. Other systems don't. Don't blame the
language for the lack of provision of Unix interprocess communication
functionality on (some) non-Unix systems.

locale determination,

It's not very well-named, but setlocale() has a query option.

EBCDIC/ASCII discrimination, etc.

Well, if those were the only two choices, it would be trivial to determine
between them: if('A' == 65) it's ASCII. But since there are many choices,
why these two in particular?

(As it turns out, very often it doesn't actually matter what character set
you're using.)

Almost all of these are easy in Perl.

That's nice.

Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these?

There is. It's called "libraries".

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

Sep 3 '08 #34

Richard Heathfield wrote:

Pilcrow said:

>Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

>Examples:
Network and internet access,

C allows you to call library functions that provide these features, but
doesn't go so far as to make their provision mandatory. (Otherwise, you
couldn't have a C implementation on a system that didn't have internet
access - and that would be silly.)

Exactly.

There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib.pl');
use strict;
my(@dirList);
ftp::debug('ON');
ftp::open('ftp.cis.ufl.edu', 'anonymous', 'm******@planet.net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ.gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");
}
----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

>
Unix systems provide this access. Other systems don't. Don't blame the
language for the lack of provision of Unix interprocess communication
functionality on (some) non-Unix systems.

Exactly. The OP is completely confusing what a computer language is, and
what an operating system is.

>locale determination,

It's not very well-named, but setlocale() has a query option.

>EBCDIC/ASCII discrimination, etc.

Well, if those were the only two choices, it would be trivial to determine
between them: if('A' == 65) it's ASCII. But since there are many choices,
why these two in particular?

(As it turns out, very often it doesn't actually matter what character set
you're using.)

>Almost all of these are easy in Perl.

That's nice.

>Why isn't there a mechanism like
perl modules to allow easy extentions for facilities like these?

There is. It's called "libraries".

Exactly. C has "modules", and the interface is simple and efficient.
There is an enormous amount of C libraries around.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 3 '08 #35

vippstar

On Sep 3, 6:07 pm, jacob navia <ja...@nospam.comwrote:

<snip>

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib.pl');
use strict;
my(@dirList);
ftp::debug('ON');
ftp::open('ftp.cis.ufl.edu', 'anonymous', 'medi...@planet.net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ.gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

And using my implementation of perl, the above program looks like
this:
f()

So what?

Sep 3 '08 #36

jacob navia said:

Kenny McCormack wrote:

<snip>

> People are pretty open about the
fact that, in today's world, C's domain is a) maintaining legacy
code and b) embedded systems.

This is the opinion of many people here, specially the regulars.

It certainly isn't my opinion.

I am really disappointed that you are basically in agreement
with them.

I don't think he is.

I am convinced that C is a language with a future,

Sure.

that can be
modified and improved to fit better the needs of software development
today without losing its inherent simplicity.

The whole C99 experience suggests that the process of changing C will not
be an easy one. That does not in itself mean that the task should not be
attempted, but it is at least a heads-up that Here Be Dragons.

All my posts, and my work building a freely distributable
C99 compiler go in that direction.

I would propose that people that think that C is dead should
keep their opinion and go to other newsgroups.

On the contrary, I would propose that they change their opinion, since
there is no point in holding onto broken opinions.

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

Sep 3 '08 #37

vi******@gmail.com wrote:

On Sep 3, 6:07 pm, jacob navia <ja...@nospam.comwrote:

<snip>

>To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl
#!/usr/bin/perl -w
require('ftplib.pl');
use strict;
my(@dirList);
ftp::debug('ON');
ftp::open('ftp.cis.ufl.edu', 'anonymous', 'medi...@planet.net') or die($!);
@dirList = ftp::list('pub/perl/faq');
ftp::cwd('/pub/perl/faq');
ftp::binary();
ftp::gets('FAQ.gz');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

@dirList = ftp::dir();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

ftp::debug();
ftp::cwd('/pub/perl/faq');
@dirList = ftp::list();
print("list of /pub/perl/faq\n");
foreach (@dirList) {
print("\t$_\n");}

----------------------------------------------perl

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

And using my implementation of perl, the above program looks like
this:
f()

So what?

Then, that proves that in any language, verbosity is a function of the
libraries that you are using!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Sep 3 '08 #38

Ben Bacarisse

jacob navia <ja***@nospam.comwrites:

Richard Heathfield wrote:
>Pilcrow said:

>>Given that UNIX, including networking, is almost entirely coded in C,
how come so many things are almost impossible in ordinary C?

I don't know of anything computable that isn't computable in ordinary C.

>>Examples:
Network and internet access,

C allows you to call library functions that provide these features,
but doesn't go so far as to make their provision
mandatory. (Otherwise, you couldn't have a C implementation on a
system that didn't have internet access - and that would be silly.)

Exactly.

There are many implementations of networking, from
Windows sockets, BSD sockets, Netware, USB networking,
Wan, LANs, etc.

To make mandatory the usage of some kind of network would
be a foolish. Besides, you can do things in C that are MUCH
more cumbersome in perl. For instance an ftp transfer in Perl
looks like this:
----------------------------------------------perl

----------------------------------------------perl

No, using the correct module it is two lines.

Using lcc-win the above program looks like this:

----------------------------------------------C (lcc-win)
int returncode = GetFtpUrl("ftp://ftp.cis.ufl.edu/pub/perl/faq","faq");
----------------------------------------------C (lcc-win)

You need at least a #include and a main function as well, no? Your C
program will be no shorter than my Perl one.

These sorts of discussions (about program length) are daft and will
often degenerate into pointless comparisons like this.

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.

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.

--
Ben.

Sep 3 '08 #39

Ben Bacarisse wrote:

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.

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.

That is why I have been insisting that we adopt the operator overloading
feature that would allow using the '[' and ']' notation for general
containers. Then, we could agree that lists/flexible arrays/arrays
and all sequential containers could be accessed with that notation and
code would be compatible.

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

Sep 3 '08 #40

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

Sep 3 '08 #41

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

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

Sep 3 '08 #42

Keith Thompson

jacob navia <ja***@nospam.comwrites:

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

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

Your gross misrepresentations 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_Keith) 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"

Sep 3 '08 #43

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

Sep 3 '08 #44

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

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
"discussions" 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

Sep 3 '08 #45

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

Sep 3 '08 #46

Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

[...]

>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

Sep 3 '08 #47

Eric Sosman

jacob navia wrote:

Keith Thompson wrote:
>jacob navia <ja***@nospam.comwrites:

[...]

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

Sep 3 '08 #48

In article <1220469839.903758@news1nwk>,
Eric Sosman <Er*********@sun.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.

Sep 3 '08 #49