lcc-win32

[CBFalconer]

.... snip ...

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.

No, many of them point out that the correct group for your
diatribes about a different standard is comp.std.c, and that this
group discusses the C that has a standard already. Thus your
suggestions are off-topic here, and annoyingly so. Your
experimental implementation is just that - experimental - since it
can not be told to meet any of the existing standards. There is
nothing wrong with that, as long as you label it correctly and
discuss it in the appropriate places.

You might consider concentrating on making it meet one of the
existing standards, either C90 or C99 (up to you), and weeding out
bugs. After that is attained (and can be proven) you can add the
experimental features with suitable disabling options, and use it
to try to convince the standards people that such features are
worthwhile for a future version of the standard.

You should also concentrate on developing regression tests. The
number of silly bug reports that I see in the lcc newgroup is
excessive. It shows that you have no way of systematically testing
changes, so revisions are not necessarily more bug free. You do
seem to be able to fix those bugs rapidly, but the results have no
easily visible revision identifier AFAICS, so the user has no idea
what he has. The fact that you suddenly lost the ability to run
the debugger on a '486 several years ago, and have no idea why, is
symptomatic.

 

[Flash Gordon]

Agreed.


Dynamic arrays don't allow arbitrary insertions and deletions in
O(1) time. That can also be wasteful in some situations.

I think we all agree (apart from Jacob) that whether you need a specific
type of data structure, or indeed anything more complex that a simple
structure or an array, depends on the problem you are trying to solve.

 

[RoSsIaCrIiLoIA]

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.[snip]

Mr Clive Feather presented a defect report for this bug, dated
2001, September 4th.

The answer of the comitee was:
[snip]
asctime() may exhibit undefined behavior if any of the members of
timeptr produce undefined behavior in the sample algorithm (for
example, if the timeptr->tm_wday is outside the range 0 to 6 the
function may index beyond the end of an array).
As always, the range of undefined behavior permitted includes:
Corrupting memory
[snip]

I think that this was the wrong answer to give to a bug report.
Problem is, bugs do not go away. You have to correct them.

Either the standard doesn't print any code (and there are
*many* other functions where writing more code would have been
useful) or then it prints a *correct* algorithm. Functions that
corrupt memory at the slightest error or malitious inputs
should be banned.

No, you can use it perfectly safely. All you have to do is check
the arguments before calling it. If erroneous you can then decide
how to compensate. For example, you can restrict the year range to
-999 .. 9999, and then correct the returned string if the original
was otherwise. It is under your control, unlike gets where the
faulty action is uncontrollable.

If you wish you can write a supervisory function to do the error
checking and return whatever you wish as an error signal. No
language change is needed, and old software will continue to
compile and run as expected.

the errors could be written in a file of os and than send it to os
maker

 

[Mark McIntyre]

Well that's my point!
A myriad but none standard, accepted by the language in
the standard library.

Ask yourself *why* none of these has been accepted as a standard (note the
small S). Is it perhaps because there is no standard need of these in C, or
no standard interface that people need or....

 

[Mark McIntyre]

Well, that's a good thing why not?

Okay, /you/ pay for upgrading all the existing code in the world. Have you
/any idea/ how expensive it would be? It would, I strongly suspect, achieve
precisely what you worry about - it would kill C. For nobody would want to
do it, and therefore no compiler writer would implement the feature in a
new version, and therefore the standard that did it would die.

strcpy et al disappear. Microsoft proposed that, and I think they
are right.

MS have a vested interest perhaps.

No. The problem is that nobody cares because the new standard doesn't
introduce enough interesting stuff to make it attractive to users.

We're not talking about the existing C99 standard, we're talking about your
controvertial proposal to remove strcpy et al. Keep with the plot please.

 

[CBFalconer]

Ask yourself *why* none of these has been accepted as a standard
(note the small S). Is it perhaps because there is no standard
need of these in C, or no standard interface that people need or...

Well, I think we can all agree it would be pleasant to have
unlimited funds rolling in. I see all sorts of intriguing
algorithms posted around here, many of which involve removing a
name and address from a text file and inserting another. I propose
that lcc-win32 should incorporate a standardized function which
will generate that file from another, and post it to all extant
newsgroups on a simple call. Once he gets that going we can all
get behind having it incorporated in the next standard.

int makemoney(FILE *infile, FILE *outfile, char *newname);

Notice that this hides all the petty nonsense of usenet connection,
passwords, timing, etc. It doesn't even need the outfile parameter
unless you wish to save it for further use.

A functional and accurate implementation should greatly improve the
popularity of lcc-win32 and thus of C. It can save lifetimes of
unspeakable drudgery. It will be the killer-ap of the 21st
century. So don't be negative, encourage M. Navia.

 

[Dan Pop]

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*

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `'
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

Dan

 

[Joona I Palaste]

_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `'
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________

This is the first time I've ever seen that applied to someone who has
successfully written and marketed his own C¹ compiler.

¹ I refuse to take a stand on the issue whether lcc-win32 correctly
implements the C standard. Therefore this "C" should not be read too
pickily.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates

 

[jacob navia]

Thanks for your remark.

Aside from polemic, the objective in this discussion is to determine if
C allows the programmer the use of simple data structures like lists,
hash tables, etc.

I stress the need of a common library, accepted as widely as the string
library, that would fill this gap, i.e. making a library where a
common interface to hash tables, to lists, to automatically growing
tables (vectors), etc is defined in the language.

I admit that this is quite new to C, but I do not see this as a big deal.

 

[Flash Gordon]

Thanks for your remark.

Aside from polemic, the objective in this discussion is to determine
if C allows the programmer the use of simple data structures like
lists, hash tables, etc.

So why did you start talking about operator overloading?

I stress the need of a common library, accepted as widely as the
string library, that would fill this gap, i.e. making a library where
a common interface to hash tables, to lists, to automatically growing
tables (vectors), etc is defined in the language.

I admit that this is quite new to C, but I do not see this as a big
deal.

As has been stated repeatedly, discussing the implementations of such
things in standard C is fine here. The problem is you telling people to
use your extensions to C such as operator overloading or telling people
to use your implementation of such things if it is not written in
standard C and freely available.

If you want to discus extending the C language or the standard C library
then that belongs in another group. Others have stated the name of the
group but I can't be bothered to look it up.

 

[jacob navia]

So why did you start talking about operator overloading?

Operator overloading is just syntatic sugar.
For hash tables, for instance, or for lists, the normal call
syntax is perfectly OK.

Syntatic sugar is needed when you want to access data structures
like a length prefixed string using the normal syntax
String a;
....
a[2] = 'b';
instead of
setStringChar(a,2,'b');
what is more cumbersome.

Since the first message in this thread (admitted, polemic)
I wanted to take a critical look at remarks like "I never use any
data structures", and such, implying that C (or programming) can
be done without using containers like hash tables, lists,
queues, etc.

As has been stated repeatedly, discussing the implementations of such
things in standard C is fine here.

OK. That is what I wanted. I think that the language is making too
difficult to do that. Each time I need a list, I have to rewrite
a new set of:
DATA_LIST *AddToList(DATA *item);
FindInList(DATA_LIST *list,DATA *item);
etc

I have done it countless times, and I think this is one of the
reasons C is perceived as a language unable to program anything serious.

> The problem is you telling people to
use your extensions to C such as operator overloading or telling people
to use your implementation of such things if it is not written in
standard C and freely available.

lcc has been always an experimental compiler where people can try
new ideas. The objective of my implementation of operator overloading
and other "extensions" is to *prove* that this can be done in a
simple way in a simple compiler. That was the objective. And I would
like that the community as a whole reflects on the possibility of
incoporating those extensions into the language, making my special
implementation unneeded.

But even without those extensions, a simple standard about lists,
would provide a much needed simplification of programs, increasing
portability and reliability. How many bugged implementations of those
lists primitives are there?

The polemic that I used (and that I regret now) arises from an
incredible feeling of frustration with a community that is slowly
drifting into obsolescence without noticing it.

I mentioned the reaction of the comitee confronted with the buffer
overflow bug written in the asctime() function in the standard.
I cited the answer to the first bug-correction proposal of Mr Cleaver
(memory overwrites are allowed) but nobody seemed to notice.

If you want to discus extending the C language or the standard C library
then that belongs in another group. Others have stated the name of the
group but I can't be bothered to look it up.

Maybe, but in comp.std.c there are more or less the same people.
I doubt it that the reaction would be different. I mentioned
(in a long thread) the fact that asctime() had a bug, but the
reaction was the same:

Nobody cares.

I have been told in this group that C++ was designed to do this
kind of stuff. This implies that C should stay in the same level
as 1989 forever, what fits nicely for people that think that only
C++ has any future.

I think that the agnostic nature of C gives the programmer a lot of
creative freedom, freedom of expression. There isn't a single,
language preferred way of doing things (OO programming) but you
can use any paradigm that fits the application best.

The complexity of C++ is so staggering, that most people, even
experts, do not understand the language in all the facets it
has. C++ has gone the "let's complxify things" until ridiculous
heights.

Confronted with that, I think that is normal that people react strongly
when presented with something that seems to go in the same
direction.

But this is not the case here.

 

[Keith Thompson]

Aside from polemic, the objective in this discussion is to determine if
C allows the programmer the use of simple data structures like lists,
hash tables, etc.

If that was all you were asking, we could have saved a lot of time.
Of *course* a programmer can use lists, hash tables, etc. in C.
People do it all the time, when it's appropriate to the problem.

In response to some earlier posts, nobody has suggested that there's
anything wrong with using dynamic data structures when appropriate.
Nor is there anything wrong with *not* using dynamic data structures
when they aren't necessary to the problem being solved.

What you're really looking for, I think, is some kind of standard
container library for C that implements lists, hash tables, etc. Why
doesn't such a thing already exist? Part of the reason, I suspect, is
that the existence of C++ has reduced the pressure to implement such a
thing in C. But whatever the reason, nobody (as far as I know) has
implemented a C container library that has really caught on. If you
want to implement one yourself, or encourage someone else to do so, go
right ahead. But complaining in comp.lang.c about the lack of a
standard C container library is likely to accomplish exactly nothing.

 

[Mike Wahler]

Thanks for your remark.

Aside from polemic, the objective in this discussion is to determine if
C allows the programmer the use of simple data structures like lists,
hash tables, etc.

It certainly does and always has. Those types of structures as well as any
others (simple or complex) that one's imagination might conceive.

I stress the need of a common library, accepted as widely as the string
library, that would fill this gap,

Many third party libraries are indeed as 'widely accepted'. I suspect
if a quick survey were taken here, we'd find many of us use some or many of
the same libraries for the same or similar tasks. Among developer teams, as
well as inter-company collaborations, many of these libraries are
'de-facto' standards for those parties. But there's no rational reason
to push these libraries down the throats of those who never need them
(i.e. all C users).

i.e. making a library where a
common interface to hash tables, to lists, to automatically growing
tables (vectors), etc is defined in the language.

I admit that this is quite new to C, but I do not see this as a big deal.

You seem to want to force everyone to eat the same amount of the
same thing, when the reality is that appetites (i.e. tool requirements)
vary extremely widely among developers. C is a 'lean' language by
design, intentionally.

This seems to offend you. Whatever.

-Mike

 

[jacob navia]

You seem to want to force everyone to eat the same amount of the
same thing, when the reality is that appetites (i.e. tool requirements)
vary extremely widely among developers. C is a 'lean' language by
design, intentionally.

A library standard doesn't have any impact in the language.
I mean, if I call
MyOwnAddTolist(DATALIST *list,DATA *item);

or if I write

StdlibcAddToList(... whatever)

the language is unchanged, but I do not have to code
a list handling code for 1000th time to cater a new
list.

And if the library function doesn't look good to me I can always
roll my own!

Library functions do not have any language impact. A standard
library makes the language just *easier to use*, that's all.

 

[Mike Wahler]

A library standard doesn't have any impact in the language.

But it does impact an implementation, which does have
a practical impact: E.g. storage space required, gobbling
up more names, etc.

I mean, if I call
MyOwnAddTolist(DATALIST *list,DATA *item);

or if I write

StdlibcAddToList(... whatever)

the language is unchanged, but I do not have to code
a list handling code for 1000th time to cater a new
list.

Use an existing library. Virtually everyone else does, rather
than re-re-re-inventing wheels.

And if the library function doesn't look good to me I can always
roll my own!

Library functions do not have any language impact. A standard
library makes the language just *easier to use*, that's all.

Yes it does, as do third party libraries.

-Mike

 

[jacob navia]

But it does impact an implementation, which does have
a practical impact: E.g. storage space required, gobbling
up more names, etc.

No. You do not want it?
Do not include
#include <stdlist.h>

The language is written according to that principle.
I can write in C:
#include <mystdio.h>

and the whole input/output of my program can be completely different
IN C. The whole library is optional. If you do not use the floating
point library (math.h) you just do not write:
#include <math.h>
and all names are still available to you and it is a legal
program.
You can then write:
myfloat mysin(myfloat arg);
and you can code the sinus function using only integer operations
and table lookups.

Yes it does, as do third party libraries.

But what... You do not use third party libs?

I would like just a standard lib, i.e. that has the same
interface in all implementations. A first step would be to
review those libs and put the best in the FAQ.

The FAQ could be used as a repository of programs that give
a common interface, is well tested and proposed as a standard lib.

Programs could be more portable if we extend standard C.

Standards enhance the software by increasing portability.

 

[Flash Gordon]

So why did you start talking about operator overloading?

Operator overloading is just syntatic sugar.
For hash tables, for instance, or for lists, the normal call
syntax is perfectly OK.

Syntatic sugar is needed when you want to access data structures
like a length prefixed string using the normal syntax
String a;
...
a[2] = 'b';
instead of
setStringChar(a,2,'b');
what is more cumbersome.

Well, for that you know you need another language.

Since the first message in this thread (admitted, polemic)
I wanted to take a critical look at remarks like "I never use any
data structures", and such, implying that C (or programming) can
be done without using containers like hash tables, lists,
queues, etc.

Not only can a lot of programing be done without using hash tables,
list, queues etc, but as I said a lot of programming *is* done without
using such things. Also the natural solution for a lot of problems does
not use such things.

OK. That is what I wanted. I think that the language is making too
difficult to do that. Each time I need a list, I have to rewrite
a new set of:
DATA_LIST *AddToList(DATA *item);
FindInList(DATA_LIST *list,DATA *item);
etc

I have done it countless times, and I think this is one of the
reasons C is perceived as a language unable to program anything
serious.

A colleague where I now work wrote a list library many years ago which
he has continued to use. I don't have it, but one possible interface
would include
data_list *AddToList(void *data, size_t len);
data_list *FindInList(data_list *list,void *item, comp_function_t
comp_function);

lcc has been always an experimental compiler where people can try
new ideas. The objective of my implementation of operator overloading
and other "extensions" is to *prove* that this can be done in a
simple way in a simple compiler. That was the objective. And I would
like that the community as a whole reflects on the possibility of
incoporating those extensions into the language, making my special
implementation unneeded.

Well, discus that in appropriate groups.

But even without those extensions, a simple standard about lists,
would provide a much needed simplification of programs, increasing
portability and reliability. How many bugged implementations of those
lists primitives are there?

Probably as many as there are buggy implementations of the standard C
library.

The polemic that I used (and that I regret now) arises from an
incredible feeling of frustration with a community that is slowly
drifting into obsolescence without noticing it.

Languages stop being used for some problem domains as other languages
better designed for those domains come along. That is the way of life in
computing and has been since the first assembler was written so that
people did not have to code directly in machine code (I have had to read
and enter machine code within the last 15 years). OO languages are
better for developing GUIs so C is used less for that now, but C is
better for other tasks.

I mentioned the reaction of the comitee confronted with the buffer
overflow bug written in the asctime() function in the standard.
I cited the answer to the first bug-correction proposal of Mr Cleaver
(memory overwrites are allowed) but nobody seemed to notice.

I read that section of the standard as specifying the algorithm to be
implemented, not the buffer size. There is nothing in the standard that
says an implementation cannot use a buffer that is large enough or
validate the inputs.

Maybe, but in comp.std.c there are more or less the same people.

I'm not there, so the population is not the same.

I doubt it that the reaction would be different.

Well, I doubt they would tell you that proposing changes to the standard
was OT especially if they have just told you in this group that it is
over their that you should discus them.

I mentioned
(in a long thread) the fact that asctime() had a bug, but the
reaction was the same:

Nobody cares.

I have been told in this group that C++ was designed to do this
kind of stuff. This implies that C should stay in the same level
as 1989 forever, what fits nicely for people that think that only
C++ has any future.

Or people who think that C has it's niche and other languages are better
for other things.

I think that the agnostic nature of C gives the programmer a lot of
creative freedom, freedom of expression. There isn't a single,
language preferred way of doing things (OO programming) but you
can use any paradigm that fits the application best.

C is not suitable for all paradigms of programming. OO programming
(and developing for GUIs) is easier in a language designed for it, list
processing is easier in a language designed for list processing (I've
played with Lisp) etc. C is just a straight forward simple procedural
language that can be used for any task that can easily be reduced to a
procedural task, and that includes most (but not all) of what I have
done in the last 19 years of programming.

The complexity of C++ is so staggering, that most people, even
experts, do not understand the language in all the facets it
has. C++ has gone the "let's complxify things" until ridiculous
heights.

Confronted with that, I think that is normal that people react
strongly when presented with something that seems to go in the same
direction.

But this is not the case here.

My reaction about your extensions is that this is the wrong place to
discus them, not that they are wrong. I just have too many other things
to think about to worry about where the C language is going. However I
do think that if you want the language to be extended the first thing to
do is get C99 implemented widely, so IMHO you efforts would be better
spent getting your implementation fully C99 compliant and making it good
enough that it persuades others to follow suit.

 

[Mark McIntyre]

Thanks for your remark.

Aside from polemic, the objective in this discussion is to determine if
C allows the programmer the use of simple data structures like lists,
hash tables, etc.

It does. Trivially.

I stress the need of a common library, accepted as widely as the string
library, that would fill this gap, i.e. making a library where a
common interface to hash tables, to lists, to automatically growing
tables (vectors), etc is defined in the language.

Fine, then go ask in comp.std.c

I admit that this is quite new to C, but I do not see this as a big deal.

Splendid. Bye then.

 

[Mark McIntyre]

Maybe, but in comp.std.c there are more or less the same people.
I doubt it that the reaction would be different.

Then you're an idiot or being disingenuous. Many of the same people
doubtless post in rec.autos as post here, or sci.math. How they react to
offtopic mumblings in one group has no bearing on how they'll react to
ontopic posts in another.

I mentioned
(in a long thread) the fact that asctime() had a bug, but the
reaction was the same:

No, you mentioned the fact that an example implementation in the standard
has a bug under highly unusual circumstsances, and the Standards committee
took a reasonable view that reprinting the standard to correct trivia was
not worthwhile.

Nobody cares.

Not any more. You've seen to that.

 

[CBFalconer]

Aside from polemic, the objective in this discussion is to
determine if C allows the programmer the use of simple data
structures like lists, hash tables, etc.

I stress the need of a common library, accepted as widely as the
string library, that would fill this gap, i.e. making a library
where a common interface to hash tables, to lists, to
automatically growing tables (vectors), etc is defined in the
language.

I admit that this is quite new to C, but I do not see this as a
big deal.

All those things are _already_ available to C programmers, except
not as a standard. All those things can be built out of C code
which meets the standard, and thus is portable. Thus the only
purpose of making such animals standard would be to hamper future
creativity. If you want to talk about the _standard_ C code to
implement such things, go ahead here. If you want to talk about
putting such things in the standard (bad idea, IMO) go to
comp.std.c. In either case, talking about them here is trolling.