New document

[jacob navia]

Hi

I have put together a document explaining most extensions of lcc-win32,
why they were done, why they could be useful, and a documentation of the
string/container library that uses those extensions.

This document is not finished but I would appreciate your feedback.

jacob

Url:

ftp://ftp.cs.virginia.edu/pub/lcc-win32/proposal.pdf

 

[Bat]

jacob navia a écrit :

Hi

I have put together a document explaining most extensions of lcc-win32,
why they were done, why they could be useful, and a documentation of the
string/container library that uses those extensions.

This document is not finished but I would appreciate your feedback.

jacob

Url:

ftp://ftp.cs.virginia.edu/pub/lcc-win32/proposal.pdf

I think this type of document is a very good thing. C is very powerful
for a lost of small utilities (and sometimes for 'not so small
utilities'). There are no indeed good tools and bad tools, there is
tools we known and tools we don't known. First one are often (not
always) the best to make things.
For the part I've read, it's good work !

 

[Robert Gamble]

Hi

I have put together a document explaining most extensions of lcc-win32,
why they were done, why they could be useful, and a documentation of the
string/container library that uses those extensions.

This document is not finished but I would appreciate your feedback.

jacob

Url:

ftp://ftp.cs.virginia.edu/pub/lcc-win32/proposal.pdf

I haven't read the entire document but here are some comments on what I
did review:

1.1 "Motivation":
"All development of C as an independent language has ceased and C has
been relegated to the past."

This is the kind of statement that most people here will consider
nonsense and is likely to keep many people from taking seriously
anything you say after that point. You even contradict yourself in the
very next sentence:

"The need for a simple and efficient language persists however, and C
is the language of
choice for many systems running today and many new ones."

So C has been relegated to the past but is still the language of choice
for many current and new systems?

"The objective of this proposal is to correct certain missing features
of C like its string library and the lack of a container library with a
few improvements that have been part of many computer languages since a
long time without introducing any new complexity or performance loss."

I don't think you can claim that the ideas in your proposal don't add
complexity or can be implemented without incurring a performance loss.

You present a couple of good points in the document, ones that may be
worth considering on their own as solutions to recognized issues in the
language. As a whole though, you seem to be proposing a number of
(what many would consider) radical changes which would really result in
an entirely new language.

I don't understand the mentality of trying to change the language to
more closely resemble other higher-level languages as opposed to using
something else that is out there or proposing a seperate language
altogether. If I need garbage collection, containers, operator
overloading, etc. I am going to use Java or Ruby or some other language
that better suits my needs. If C was retrofitted with all the extras
that you are proposing it wouldn't make it more attrative to me for
such tasks and would make the langauge less attractive for the things I
currently use it for. The net result would, I believe, push people
away from the language. There hasn't been much demand for many of the
features you discuss and given the reception of the C99 Standard, which
included many features that were in greater demand than your
suggestions, I don't think you are likely to get a warmer reception
from the C community.

My suggestion is to either focus on one or two ideas that address
issues that really matter to the C community (buffer overflow
prevention and string abstractions seem to be hot right now) and are
implemented in ways that are likely to be well-received or just propose
the creation of a new language (like D did).

Robert Gamble

 

[CBFalconer]

I haven't read the entire document but here are some comments on
what I did review:

1.1 "Motivation":
"All development of C as an independent language has ceased and C
has been relegated to the past."

This is the kind of statement that most people here will consider
nonsense and is likely to keep many people from taking seriously
anything you say after that point. You even contradict yourself
in the very next sentence:

I was planning to at least read his proposal, but your quote in
itself has deterred that.

Let me point out that all development of the French language has
ceased, not because of lack of innovation, but because of legal
barriers erected in both France and Quebec. I believe use of the
phrase "le hotdog" is now cause for incarceration in the Bastille.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Al Balmer]

Hi

I have put together a document explaining most extensions of lcc-win32,
why they were done, why they could be useful, and a documentation of the
string/container library that uses those extensions.

This document is not finished but I would appreciate your feedback.

jacob

Url:

ftp://ftp.cs.virginia.edu/pub/lcc-win32/proposal.pdf

First paragraph, third sentence:
"All development of C as an independent language has ceased and C has
been relegated to the past."

Ah, well, it's just another advertisement for Jacob, after all. I
didn't bother to read further.

 

[Eric Sosman]

First paragraph, third sentence:
"All development of C as an independent language has ceased and C has
been relegated to the past."

Ah, well, it's just another advertisement for Jacob, after all. I
didn't bother to read further.

I read further, but eventually just skimmed. (I think
there's an error in the use of a va_alist in one of his code
samples, but wasn't sufficiently motivated to track it down.)
His contentious style is off-putting (one of his "Motivation"
sections consists entirely of "Everybody agrees FALSEHOOD,"
which doesn't encourage rational argument), but I think there
is serious thought behind the polemics. There may be something
worth while amid the noise.

"Worth while to C," however, is another matter. I believe
the wrenching changes he advocates would simply misappropriate
the label "C" to designate some entirely different language --
and it's likely this language would be unacceptable both to the
"C as it is" crowd and to the "C -- that's SO last millennium"
crowd. The language he describes isn't so much "C improved"
as "C with too much makeup."

Skimming, skimming ... He's got an example of how to overload
the == operator to apply to strings (sorry, Strings), and all of
a sudden there's this Exception doodad creeping into the picture.
Hello? Can't I compare two [Ss]trings without risking an Exception,
whatever that might be? I'd sure hate to be in the middle of the
ISR portion of a device driver when one of those cut loose ...

The paper is entitled "New Directions in C," and it seems to
me that both parts of the title are debatable. The "directions"
don't seem very "new" -- the paper makes a point of listing other
languages that incorporate similar features (but doesn't bother to
assess whether the result is good or bad), so the "newness" is
suspect. As for the second part, the "in C" portion seems
completely unjustified -- consider what the shibboleth of "safety"
has done to pointers in, in, well, we might call it J.

C is not perfect, and I am no defender of its holiness. But
the language JN describes is not C, not any more than Charlemagne
was Holy Roman Emperor or the Czars the inheritors of the Caesars.

 

[Walter Roberson]

The paper is entitled "New Directions in C," and it seems to
me that both parts of the title are debatable.

As for the second part, the "in C" portion seems
completely unjustified -- consider what the shibboleth of "safety"
has done to pointers in, in, well, we might call it J.

J is Iverson's post-modernization of APL.
http://www.jsoftware.com

 

[Richard Heathfield]

Al Balmer said:

First paragraph, third sentence:
"All development of C as an independent language has ceased and C has
been relegated to the past."

Ah, well, it's just another advertisement for Jacob, after all. I
didn't bother to read further.

I didn't even bother to read /that/ far, since he made no effort to make the
document easily readable. HTML would have worked. Text would have worked
even better. But I'm not going to fire up a program that isn't already
kicking around my /proc, just to read Navia's proposals - at least not
until it's evident that he's found a clue or two from somewhere.

Given the line you've quoted, though, it makes no sense whatsoever for him
to post his proposals in clc, since they clearly have nothing to do with
using the C language.

I fail to see how /anyone/ that - um - challenged can write a C compiler.

 

[jacob navia]

Robert Gamble a écrit :

I don't think you can claim that the ideas in your proposal don't add
complexity or can be implemented without incurring a performance loss.

There is NO performance loss.

None of the proposed changes is automatic and none affects any other
part of the language. This means that performance of C stays the same
when the changes are not used.

The objective of those changes is to furnish the tools for building a
good standard library, specially a good string library.

C has become a synonym for "buffer overflow vulnerability". Let's stop
this.

You present a couple of good points in the document, ones that may be
worth considering on their own as solutions to recognized issues in the
language. As a whole though, you seem to be proposing a number of
(what many would consider) radical changes which would really result in
an entirely new language.

Fortran has adopted operator overloading, Delphi, many other languages
have done that without becoming "a new language". Let's keep our senses.

I don't understand the mentality of trying to change the language to
more closely resemble other higher-level languages as opposed to using
something else that is out there or proposing a seperate language
altogether. If I need garbage collection, containers, operator
overloading, etc. I am going to use Java or Ruby or some other language
that better suits my needs.

That is why C should not be used at all. Who doesn't need strings, or
containers, in any serious programming? Of course we should use "the
better C", i.e. C++ and stop whinning about a primitive language that
should disappear isn't it?

If C was retrofitted with all the extras
that you are proposing it wouldn't make it more attrative to me for
such tasks and would make the langauge less attractive for the things I
currently use it for.

Why. The changes in the lcc-win32 compiler needed to accomodate ALL that
were just 2000 lines of code!

The net result would, I believe, push people
away from the language.

Most people are pushed away from the language the nth time they have
to keep track of the possible buffer overflows, the nth time they have
to code a linked list!

There hasn't been much demand for many of the
features you discuss and given the reception of the C99 Standard, which
included many features that were in greater demand than your
suggestions, I don't think you are likely to get a warmer reception
from the C community.

Complex arithmetic? In greater demand that a sane string library?

My suggestion is to either focus on one or two ideas that address
issues that really matter to the C community (buffer overflow
prevention and string abstractions seem to be hot right now) and are
implemented in ways that are likely to be well-received or just propose
the creation of a new language (like D did).

My point is that without abandoning null terminated C strings there is
NO CHANCE we can write a sensible string library.

 

[Ian Collins]

Robert Gamble a écrit :

Fortran has adopted operator overloading, Delphi, many other languages
have done that without becoming "a new language". Let's keep our senses.



That is why C should not be used at all. Who doesn't need strings, or
containers, in any serious programming? Of course we should use "the
better C", i.e. C++ and stop whinning about a primitive language that
should disappear isn't it?

A lot of people have. I tend to use C++ as a first choice these days.
I still use C when that choice isn't available.

I'm sure a lot of people do the same, which might go some way to
explaining the lack of interest in extending C. C does what it does
very well, if you want to do something C doesn't do well, don't use it.

 

[Richard Heathfield]

jacob navia said:

C has become a synonym for "buffer overflow vulnerability".

Yes, in the same way that "jacob navia" has become a synonym for "off-topic
troll". And, just as it is not only possible but easy to avoid buffer
overflows in C, so it is not only possible but easy for Jacob Navia to stop
posting idiotic ramblings in clc.

Let's stop this.

Whenever you're ready, just stop.

That is why C should not be used at all.

If you really believe that, then stop using it, and drop support for it from
your compiler. If you don't stop using it, or don't drop support for it
from your compiler, then you don't really believe it should not be used.

Who doesn't need strings, or
containers, in any serious programming? Of course we should use "the
better C", i.e. C++ and stop whinning about a primitive language that
should disappear isn't it?

The language I choose to use is my decision, not yours.

Most people are pushed away from the language the nth time they have
to keep track of the possible buffer overflows,

A little care is all that is required.

the nth time they have to code a linked list!

n = 1, if you do it properly the first time.

My point is that without abandoning null terminated C strings there is
NO CHANCE we can write a sensible string library.

<shrug> I can write a sensible string library without rewriting C.
Conversion between C strings and my strings is reasonably trivial, so I get
the best of both worlds. I expect you could do that too, if you tried. But
wait! You think people should stop using C. Fine, so stop using it, end of
problem. The rest of us will carry on as *we* see fit.

 

[CBFalconer]

Robert Gamble a écrit :
.... snip ...


Most people are pushed away from the language the nth time they
have to keep track of the possible buffer overflows, the nth time
they have to code a linked list!

Why do you think a linked list is so hard to code? You have to
define what you are linking to start with:

struct node {
struct node *next;
T data;
};

Now you need a function to create such a node:

struct node *makenode(T datum) {
struct node *newnode;

if (newnode = malloc(sizeof *newnode)) {
newnode->data = datum;
newnode->next = NULL;
}
return newnode;
}

and using it is dead simple

struct node *list = NULL;
struct node *temp;

...
while (getmoredata()) {
if (NULL == (temp = makenode(datum)))
giveupforlackofmemory();
else {
temp->next = list;
list = temp;
}
}

and I think any quasi-capable programmer should be able to write
that in his moribund sleep.

You don't like the list order? Well, you are free to change it,
either by reversing the list when done, or by changing the actual
entry operations, depending on need. No need for a monstrous piece
of library code with twenty-eight and a half options.

You want a sorted list? Maybe a list isn't the optimum data
structure. Maybe sorting the completed list is suitable. Enter
mergesort, also extremely simple coding.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

.... snip ...

I fail to see how /anyone/ that - um - challenged can write a C
compiler.

He didn't. He bought a licence for portable lcc, reworked the code
generator etc. to use Windoze, and has been modifying ever since.
His version of lcc is about 10 or more revisions behind the
original one. His original work has, I believe, been in the editor
and debugger areas, and in system integration to Windoze. These
are not trivial works.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Friedrich Dominicus]

I fail to see how /anyone/ that - um - challenged can write a C
compiler.

How about cleaning the front of you house?

I fail to see how /anyone/ that - um - challenged can write a C book.

Friedrich

 

[Eric Sosman]

jacob navia wrote On 05/16/06 02:30,:

Robert Gamble a écrit :



There is NO performance loss.

None of the proposed changes is automatic and none affects any other
part of the language. This means that performance of C stays the same
when the changes are not used.

The objective of those changes is to furnish the tools for building a
good standard library, specially a good string library.

C has become a synonym for "buffer overflow vulnerability". Let's stop
this.

Ignoring the contentious tone, how does this jibe with
the earlier statement about performance staying the same if
the changes are not used? If the changes are not used there
is no improvement in safety from buffer overflow, is there?

Long ago there was a series of humorous advertisements
for a brand of gasoline, each beginning with an outrageous
claim made by a big-voiced announcer and followed by a sort
of fine-print disclaimer delivered sotto voce:

"One tank of Pluperfect Petrol will last for YEARS!!!"

"(([if you don't drive your car]))"

... and there's something about "NO performance loss (([if
you don't use the features]))" that reminds me of that old
ad campaign.

 

[jacob navia]

Eric Sosman a écrit :

jacob navia wrote On 05/16/06 02:30,:



Ignoring the contentious tone, how does this jibe with
the earlier statement about performance staying the same if
the changes are not used? If the changes are not used there
is no improvement in safety from buffer overflow, is there?

Obviously you think that scanning memory for the terminating zero is
vastly more efficient than accessing it directly with the string length.

Each time you access the length of a zero terminated string you must
start that unbounded memory scan, source of countless errors. Operations
like strcat depend on the length of the first string, that must be
recalculated over and over.

Obviously you have a different concept for "efficiency" than I do.

Length delimited strings are INHERENTLY faster than zero terminated ones.

Is that too difficult for you to understand?

 

[Eric Sosman]

jacob navia wrote On 05/16/06 10:01,:

Eric Sosman a écrit :



Obviously you think that scanning memory for the terminating zero is
vastly more efficient than accessing it directly with the string length.

Each time you access the length of a zero terminated string you must
start that unbounded memory scan, source of countless errors. Operations
like strcat depend on the length of the first string, that must be
recalculated over and over.

Obviously you have a different concept for "efficiency" than I do.

Length delimited strings are INHERENTLY faster than zero terminated ones.

Is that too difficult for you to understand?

Not one word of this -- well, "response" isn't right,
because it's not responsive -- not one word of this post
addresses the question raised. Once again, for those who
may not have been paying attention:

The claim is made that "There is NO performance
loss." [JN's exact words]

This claim is defended by saying that "[...]
performance of C stays the same when the changes
are not used." [JN's exact words]

My question: If the changes are not used, is C
improved in any way at all?

If you read very v-e-r-y carefully, you will note that
I made no claims about whether counted strings were faster
or slower, safer or more hazardous, slimmer or more fattening.
I simply asked you to explain how "changes [...] not used"
can be an improvement.

Is that too difficult for you to understand?

 

[Flash Gordon]

Eric Sosman a écrit :

Obviously you think that scanning memory for the terminating zero is
vastly more efficient than accessing it directly with the string length.

Each time you access the length of a zero terminated string you must
start that unbounded memory scan, source of countless errors. Operations
like strcat depend on the length of the first string, that must be
recalculated over and over.

Strangely enough, my programs don't depend on doing lost of strca and
strlen calls.

Obviously you have a different concept for "efficiency" than I do.

Length delimited strings are INHERENTLY faster than zero terminated ones.

Is that too difficult for you to understand?

So tell me, if I'm adding one character at a time to a string, keeping a
pointer to the end of the string, how is something equivalent to:
*p++ = whatever;
going to be slower than something equivalent to:
*p++ = whatever;
increment the length of the string p points in to

It seems to me that the latter is going to be slower.

The same applies to pieces of code I have that build up strings from
constant strings. They keep track of the end of the string and a lot of
the time they know in advance how long the string is that will be added.

There is no system that is going to be the fastest in every situation,
and if I want counted strings I can implement them just as Paul Heisch
(sorry, I've probably spelt your name wrong) has.

For some of my string handling I far prefer the way other languages do
it where you don't have to worry about allocating space but instead the
buffer grows as you add to it. It does a lot to get rid of buffer
overflows, but that does not mean I think it is right for all uses or for C.

 

[Giannis Papadopoulos]

Robert Gamble a écrit :

There is NO performance loss.

None of the proposed changes is automatic and none affects any other
part of the language. This means that performance of C stays the same
when the changes are not used.

The objective of those changes is to furnish the tools for building a
good standard library, specially a good string library.

C has become a synonym for "buffer overflow vulnerability". Let's stop
this.

If we did check every now and then for buffer overflows, there would be
some perfomance loss.

Do you have any hard evidence that C's perfomance is not impaired by the
new additions?

FYI: A colleague informed me that lcc-win32 gave extremely bad
perfomance results compared to mingw. I cannot support such a statement,
as I only use linux. Is this because of the new additions?


--
one's freedom stops where others' begin

Giannis Papadopoulos
Computer and Communications Engineering dept. (CCED)
University of Thessaly
http://dop.freegr.net/

 

[jacob navia]

Giannis Papadopoulos a écrit :

If we did check every now and then for buffer overflows, there would be
some perfomance loss.

Yes.

At 3GHZ the price to pay for a memory comparison with a constant should
be noticeable after some BILLION comparisons...

Buffer overflows however, are not a "performance" problem?

Does incorrect software "perform" OK ???

Do you have any hard evidence that C's perfomance is not impaired by the
new additions?

If you check bounds when using strings the performance loss will not be
noticeable in most PCs. It could be a problem in some old embedded
systems. Embedded systems, for instance the Analog devices new CPUs are
32 bits monsters where the above performance problems do not apply.

Besides, if you are working in a slow 50MHZ CPU, you can always use the
old interface. People with newer machines can use a better approach.

It means do we level by the worst common denominator?

Or by the best?

FYI: A colleague informed me that lcc-win32 gave extremely bad
perfomance results compared to mingw. I cannot support such a statement,
as I only use linux. Is this because of the new additions?

This is absolutely unverifiable. You should come with *some* data to
justify that.

gcc however, is a better compiler than lcc-win32 in general.

The source of gcc is approx 15MB of C, the source of lcc-win32 is just 800K.

Benchmarks tell me that I am running at approx 70-80% of fully optimized
MSVC.

With gcc it depends, but should be like 80%. (i.e. I am running at 80%
gcc's speed)