lcc-win32

J

jacob navia

<< QUOTE
It is NOT a C compiler, because it doesn't conform to any commonly
accepted C specification (K&R, C89, C99). You have no right to call it
a C compiler until you get it to conform
quote >>

lcc-win32 provokes unexpected passions in some people using this
newsgroup. It is a H compiler then (H for heretical, non-orthodox)

<< QUOTE
It's been 12 years since I've used a binary tree the last time. In the
meantime, the most complex data structure I *needed* to use was an array
of structures. And I suspect that many programmers use linked lists
only in their homework assignments.
quote >>

The H compiler is not heretical by chance. I am heretical too. I have
to confess to you now that I do use hash tables, lists, and many other
structures in my day-to-day programming.

Worst, I am convinced that designing clever data structures is the best
of the programming activity.

You can get a copy of the H compiler from:
http://www.cs.virginia.edu/~lcc-win32
 
B

Ben Pfaff

jacob navia said:
<< QUOTE ... >>

If you're going to quote an article, then you should also supply
a References: header so that we can read the article in question.
It's difficult to respond to anything that incomplete.
 
J

jacob navia

Ben said:
If you're going to quote an article, then you should also supply
a References: header so that we can read the article in question.
It's difficult to respond to anything that incomplete.

Well, look, I didn't want to give a prize to somebody...

I do not like personal attacks. From the prose,
is not too difficult to know who I am talking about.

jacob
 
R

Randy Howard

Well, look, I didn't want to give a prize to somebody...

Being quoted is a prize? Since when? I guess you just got a prize
then, but it hardly seems worth worrying about.
 
D

Default User

jacob navia wrote:
I do not like personal attacks.

And I don't like your constant off-topic drivel.
From the prose,
is not too difficult to know who I am talking about.


Yeah, it is. I have no idea. Fortunately, I don't really care. This
crap is off-topic and belongs in your own personal advocacy group (as
if anyone else would be interested).




Brian Rodenborn
 
M

Mike Wahler

jacob navia said:
Well, look, I didn't want to give a prize to somebody...

I do not like personal attacks.

I see no evidence of a personal attack by Ben in his reply
to you, or in the material you quoted. All I see is a complaint
in Ben's reply that you gave insufficient context.
From the prose,
is not too difficult to know who I am talking about.

Sure it is, unless you make the invalid assumption that
the reader is somehow already familiar with someone's
personality or writing style, or with a previous dispute.
This could easily be the first article by you that someone
is reading.

Now my turn to complain: One of the behaviors on Usenet
I dislike the most is the omission of attributions for
quoted material.

-Mike
 
K

Keith Thompson

jacob navia said:
<< QUOTE
It is NOT a C compiler, because it doesn't conform to any commonly
accepted C specification (K&R, C89, C99). You have no right to call it
a C compiler until you get it to conform
quote >>

lcc-win32 provokes unexpected passions in some people using this
newsgroup. It is a H compiler then (H for heretical, non-orthodox)

Is lcc-win32 a C compiler or not? If it fails to conform to the C
standard (whichever one you choose to try to implement), are those
failures deliberate, or are they bugs or limitations to be fixed in a
future release?

If its failures to conform are few and fixable, I'd be willing to call
it a C compiler with a few bugs. Nearly all software has bugs; I lack
any real basis for knowing whether lcc-win32 is unacceptably buggy.

If it's far enough from C conformance that it doesn't qualify as a C
compiler, then it's clearly off-topic here. Again, I lack any real
basis for knowing whether this is the case.

If your intent in referring to it as "an H compiler" is to have an
argument with the source of the above quote (yes, I know who it is),
I submit that you are wasting your time (which is perfectly fine with
me) and ours (which isn't).
 
J

jacob navia

The assumption that C programming means ignoring data structures
is widespread in this group.

I quoted one of the people that posts the most of such nonsense, but
in the thread about containers, a week ago, some people said that they
do not use *any* data structures whatsoever.

This conservative attitude was repeated when we spoke about operator
overloading.

This, is reflected in the standards comitee too: I discovered a buffer
overflow in the code of the asctime function, printed in the standard.

Then, I was told that somebody else had already presented a correction
for this bug in 2001 and that the comitee said that it doesn't care,
explicitely endorsing memory overwrites.

That is why I do not care to quote exactly the name of the people
that said that. Because I want to attack that attitude of blind
conservatism where C is considered a language for unsophisticated
brutes :)

A dead language. A language where it is allowed to say:

"Innovation is off topic here"

in the group that is supposed to discuss the language.

The group degrades to a free help desk for the ethernal
questions about whether i = i++; or fscanf or sscanf
problems.

Discussing about data structures, containers, and all the
associated problems is off topic, the language is perceived
as dead. Not even C99 comes clear, as the discussion about
the introducing "bool" in the FAQ showed.

C is C89. Ahh nostalgie... We were 15 years younger then.

I repeat:

The advantage of C is that is not "object oriented",
neither "list oriented" like lisp, nor array oriented
like APL.

This agnostic nature of C is precisely a big freedom.

But it comes at a prize. It means that abstractions
are difficult to implement and generalize.

C++ introduced many ideas besides this object oriented
stuff. Operator overloading is quite simple conceptually:

You call a user defined function at each operation between
two user defined types.

This way you can define arbitrary kind of numbers.

This is useful and used in many, not OO oriented
languages.

Generic functions, default function arguments, and
many other things *are* useful. I do not want any
C++ but is obvious that non object-oriented features
like those mentioned above would make C easier to use.

But since most people are convinced that the language is
dead, that is it.
 
J

jacob navia

The assumption that C programming means ignoring data structures
is widespread in this group.

I quoted one of the people that posts the most of such nonsense, but
in the thread about containers, a week ago, some other people said
that they do not use *any* data structures whatsoever.

Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?

This is the problem.

How could such a library look like?

What are the difficulties we find when trying to build
such a library?

I mean the whole attitude of forbidding any development
in C as such, and saying to people to move to C++.

Isn't that just destroying it? Destroying C as a living language?
 
F

Flash Gordon

The assumption that C programming means ignoring data structures
is widespread in this group.

I quoted one of the people that posts the most of such nonsense, but
in the thread about containers, a week ago, some other people said
that they do not use *any* data structures whatsoever.

No one said they didn't use *any* data structures. Some of us pointed
out that for the jobs we had spent several years doing we did not need
any *complex* data structures.
Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?

This is the problem.

How could such a library look like?

What are the difficulties we find when trying to build
such a library?

If you want to post the bits of such a library written in standard C
that you have problems with then fine, we will discuss it. However, you
instead keep going on about your non-standard extensions.
I mean the whole attitude of forbidding any development
in C as such,

I do a lot of development in C. If, however, you mean proposing changes
to the language then I believe there is another group for that.
and saying to people to move to C++.

Isn't that just destroying it? Destroying C as a living language?

Since a number of us make a good living out of C development I doubt
many here are destroying it.
 
M

Mike Wahler

[snip]
A dead language. A language where it is allowed to say:

"Innovation is off topic here"

in the group that is supposed to discuss the language.
[snip]

But since most people are convinced that the language is
dead, that is it.

C is dead. Don't use it. Go use something else (but
please don't talk about it here). Bye-bye!

-Mike
 
M

Mike Wahler

jacob navia said:
The assumption that C programming means ignoring data structures
is widespread in this group.

I quoted one of the people that posts the most of such nonsense, but
in the thread about containers, a week ago, some other people said
that they do not use *any* data structures whatsoever.

Some do, some do not (but of course this depends upon
the debatable definition of 'data structure'). A case
can be made that a C type 'int' object is a 'data structure'
(i.e. a sequence of bits).

Data structures are not topical here. I suppose you'll object,
"what use is C if I can't use it to create data structures?"
I'll admit that would limit its use. But that argument is akin
to going to a group which discusses classic cars, and insisting
that locations of restaurants are topical, since you drive to
them in your classic car.
Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?

Because there isn't. Feel free to create one, and convince
enough people that it's useful enough to standardize. But
please don't do it here. This group is for discussing C
as it is. For discussing enhancements and future directions
for C, visit comp.std.c
This is the problem.

How could such a library look like?

What are the difficulties we find when trying to build
such a library?

I mean the whole attitude of forbidding any development
in C as such,

Nobody is forbidding you to do anything. I (and others)
are requesting that you keep your posts here topical.
and saying to people to move to C++.

Isn't that just destroying it? Destroying C as a living language?

C seems very much alive to me. I use it virtually every day,
and find it very useful. I also use C++, and other languages too.
I don't pretend that any of them should be something other than
what it is, or that a language should be one of the others.

-Mike
 
C

CBFalconer

jacob said:
.... snip ...

Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?

This is the problem.

How could such a library look like?

There are myriad libraries (but not standardized libraries)
available for those things. I have provided one for hash tables,
others have provided ones for the other items you mentioned. Mine
is written in standard C, and thus should port everywhere. Yours
don't, and thus are off-topic here.
 
J

jacob navia

Mike said:
The assumption that C programming means ignoring data structures
is widespread in this group.
[snip]
Data structures are not topical here. [snip]
Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?


Because there isn't.

Ahhh very clear.

Your objective is destroying C, leaving people either with the
complexity of full C++ or with a language that produly features a
buffer overflow in its standard text (asctime()) and will never
change it because the language should be kept *AS IT IS*

Mostly, the answers I get are just insults (Mr Pop), or "go away"
(you) or similar nonsese.

There isn't even the hint of a conceptual discussion, that is avoided at
all costs since you and Mr Pop have nothing to say.

jacob
 
M

Mark McIntyre

The assumption that C programming means ignoring data structures
is widespread in this group.

Where on earth did you get that bizarre idea? You think that because
discussion of lcc's container classes is offtopic, , people deny
containers' existence in general? Come on, wake up!
I quoted one of the people that posts the most of such nonsense, but
in the thread about containers, a week ago, some people said that they
do not use *any* data structures whatsoever.

Well, thats impossible isn't it since even a FILE* is a data structure, and
its reasonably hard to write a C programme witnout using one of those. What
people actually said, if you think back, is that they had no regular use
for containers of the type you want to discuss. For instance I myself
virtually never use them, since arrays of structs typically suffice for the
type of data access I need.
This conservative attitude was repeated when we spoke about operator
overloading.

Again, I almost never use this. Its simply not needed in my line of work.
Thats not to say that its not needed *at all*, heavens no, its jolly
useful. When you need it. And when I *do* need it, I will use C++, which as
it happens is a language designed with that sort of thing in mind. And
jolly useful too.
This, is reflected in the standards comitee too: I discovered a buffer
overflow in the code of the asctime function, printed in the standard.

Come on, get a brain ! The code in the standard is not an implementation,
its a snippet showing the principle.
Then, I was told that somebody else had already presented a correction
for this bug in 2001 and that the comitee said that it doesn't care,
explicitely endorsing memory overwrites.

I don't believe that, and your remark is close to libel by the way. I'm
prepared to believe that the committee doesn't consider it worth correcting
at this stage, as its a trivial error much along the same lines as a
spelling mistake.
A dead language. A language where it is allowed to say:

"Innovation is off topic here"

Thats *never* been said. But this group is to discuss the language, not the
Standard. If you want to discuss the standard, go over to comp.std.c.
in the group that is supposed to discuss the language.

So discuss it, don't discuss hypothetical languages similar to C but with
nonstandard extensions.

(rest of the rant snipped, I got tired reading it)
 
M

Mark McIntyre

On Sat, 09 Oct 2004 01:44:30 +0200, in comp.lang.c , jacob navia

(the same thing he posted about 5 other times)

Is your answer to any post going to be to totally ignore it, and instead
repost your diatribe? Why not instead actually respond to people?
Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?

Have you asked the standards committee, or asked over in comp.std.c where
its topical? If you really think this is a worthwhile addition to C, you
should put it forward formally. The committee, who lets remember come from
all avenues of C life and have wide-ranging experience, will certainly be
able to make an informed decision. Unlike you and I.
This is the problem.

The problem is, why do you persist in arguing about offtopic stuff here?

I started out this thread sort-of on your side, prepared to give lcc a try,
cut it some slack. Now, if someone working for me tried to use it, I'd have
the disk reformatted, and if necessary, revoke the person's access to the
internet and/or oxygen as applicable.
Isn't that just destroying it? Destroying C as a living language?

Nope.
 
M

Mark McIntyre

Ahhh very clear.

Your objective is destroying C,

Oh, grow up you silly silly person.
There isn't even the hint of a conceptual discussion, that is avoided at
all costs since you and Mr Pop have nothing to say.

There isn't a hint of discussion because... wait for it....

ITS FSCKING WELL OFFTOPIC YOU CRETIN.

Can't you get this into your thick skull? This is comp.lang.c, not
comp.std.c. Go peddle your wares in the right bloody place.
 
A

Arthur J. O'Dwyer

Come on, get a brain ! The code in the standard is not an implementation,
its a snippet showing the principle.


I don't believe that, and your remark is close to libel by the way. I'm
prepared to believe that the committee doesn't consider it worth correcting
at this stage, as its a trivial error much along the same lines as a
spelling mistake.

Where's the error? I checked N869, and it looks fine to me; it supplies
a buffer 'char result[26]' for holding a 25-character string plus null
terminator. Unless Jacob is thinking that it'll stop working correctly in
the year 10000; but that's not a reasonable complaint in my book.
So, what's the deal here?

Oh... I just checked Google Groups, and it looks like my guess was
right. Well, maybe by the year 10000 we'll all have succeeded in
killing C, and it won't be a problem any more.

-Arthur,
what, is this thing still on?
 
M

Mike Wahler

jacob navia said:
Mike said:
The assumption that C programming means ignoring data structures
is widespread in this group.
[snip]
Data structures are not topical here. [snip]
Why there isn't a standard library in C for lists, length delimited
strings, hash tables, stacks, etc?


Because there isn't.

Ahhh very clear.

Crystal clear. Black and White. A is A.
Your objective is destroying C,

How do you know what my objectives are? But for your
information, I highly value the C language, and use
it virtually every day. It puts food on my table.
Why would I want to destroy it?
leaving people either with the
complexity of full C++ or with a language

I'm not concerned with which languages other people choose
to use or not. That's up to them.
that produly features a
buffer overflow in its standard text (asctime())
and will never
change it

That's a ridiculous claim. How can a written specification
contain a 'buffer overflow'? It contains no buffers at all.
It also makes no requirements about the sizes of any buffers.
because the language should be kept *AS IT IS*

Please cite one occasion where anyone has made this assertion.

Mostly, the answers I get are just insults (Mr Pop), or "go away"
(you) or similar nonsese.

I'm normally very patient with folks here. But for a period of
*years* you've been coming here and posting off topic material,
as well as disparaging the language we discuss here. I finally
had my fill. How would you feel if I continually bad-mouthed
one of your favorite things?
There isn't even the hint of a conceptual discussion,

Conceptual discussions about C are topical here (although
practical ones are indeed far more common). What you're proposing to
discuss is not C. If you want to discuss changing the language,
go to comp.std.c, where such things *are* topical. I believe I've
already said this.
that is avoided at
all costs

Huh? I have on occasion asked about and/or explained concepts
of C here. One must understand its concepts in order to use it
effectively.
since you and Mr Pop have nothing to say.

We both have plenty to say, and have said much, *about C*.
Some of what I've said (about C) was pointed out by some
to be incorrect (probably at least a few times by Mr. Pop),
for which I thank them for furthering my education.

-Mike
 
J

jacob navia

Arthur said:
Come on, get a brain ! The code in the standard is not an implementation,
its a snippet showing the principle.



I don't believe that, and your remark is close to libel by the way. I'm
prepared to believe that the committee doesn't consider it worth
correcting
at this stage, as its a trivial error much along the same lines as a
spelling mistake.


Where's the error? I checked N869, and it looks fine to me; it supplies
a buffer 'char result[26]' for holding a 25-character string plus null
terminator. Unless Jacob is thinking that it'll stop working correctly
in the year 10000; but that's not a reasonable complaint in my book.
So, what's the deal here?

The deal is that the principle that never a library function should have
memory overwrites is breached.

All functions in the library should return an error code if confronted
with invalid inputs. It suffices for a malitious program to pass wrong
data (or a program that contained an error already passed uninitialized
memory, etc) to provoke memory overwrites.

Memory overwriting functions can be used as a lever to write certain
pointer values in another data structure, for instance. Actually, in
the discussion in comp.lang.c nobody disputed the fact that this is a bug.

Software written in C can be written such that this doesn't appear.
There is very little code in the standard, but the code that is written
there should be right.

That's the deal here.
Oh... I just checked Google Groups, and it looks like my guess was
right. Well, maybe by the year 10000 we'll all have succeeded in
killing C, and it won't be a problem any more.

It is already done almost. Your work has been successful.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top