lcc-win32

[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

[Ben Pfaff]

jacob navia <ja***@jacob.remcomp.fr> writes:

<< 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.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[jacob navia]

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

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

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

[Randy Howard]

In article <41**********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says...

Ben Pfaff wrote:

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

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

--
Randy Howard (2reply remove FOOBAR)
"Show me a young Conservative and I'll show you someone with no heart.
Show me an old Liberal and I'll show you someone with no brains."
-- Winston Churchill

[Mike Wahler]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr...

Ben Pfaff wrote:

jacob navia <ja***@jacob.remcomp.fr> writes:

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

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

[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

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

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

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

[Mike Wahler]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

[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

[Mike Wahler]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr...

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

[Flash Gordon]

On Sat, 09 Oct 2004 01:44:30 +0200
jacob navia <ja***@jacob.remcomp.fr> wrote:

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[CBFalconer]

jacob navia wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[jacob navia]

Mike Wahler wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr...

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

[Mark McIntyre]

On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Sat, 09 Oct 2004 01:44:30 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

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

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Sat, 09 Oct 2004 11:45:48 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Mike Wahler wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr...

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,

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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Arthur J. O'Dwyer]

On Sat, 9 Oct 2004, Mark McIntyre wrote:

On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote:

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.

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?

[Mike Wahler]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

Mike Wahler wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr...

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

[jacob navia]

Arthur J. O'Dwyer wrote:

On Sat, 9 Oct 2004, Mark McIntyre wrote:

On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote:

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.

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.

[jacob navia]

Dear "Deafult user"

When all cases are exhausted, there is always the default.

Your answer is by "default":

"crap", "go away" "off topic". Can't you articulate?

I am speaking about data structures and their neglect in C.
I remind that security and avoiding buffer overflows is
important. This is off topic?

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

[...]

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.

I'm afraid that it's a little more than that.

C99 7.23.3.1 says:

The asctime function converts the broken-down time in the
structure pointed to by timeptr into a string in the form

Sun Sep 16 01:03:52 1973\n\0

using the equivalent of the following algorithm.

char *asctime(const struct tm *timeptr)
{
static const char wday_name[7][3] = {
"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
};
static const char mon_name[12][3] = {
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
};
static char result[26];

sprintf(result, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",
wday_name[timeptr->tm_wday],
mon_name[timeptr->tm_mon],
timeptr->tm_mday, timeptr->tm_hour,
timeptr->tm_min, timeptr->tm_sec,
1900 + timeptr->tm_year);
return result;
}

The implication is that a call to asctime() invokes undefined behavior
if the result doesn't fit into the 26-byte result buffer (e.g., if the
argument represents a date after the year 9999 or before -999).

It also invokes undefined behavior if timeptr is null or invalid, if
timeptr->tm_wday is outside the range 0..6, if timeptr->tm_mon is
outside the range 0..11, or if any of timeptr->tm_mday, timeptr->tm_hour,
timeptr->tm_min, or timeptr->tm_sec is outside the range -9..99
(or a larger range if the %d conversion for 1900+timeptr->tm_year
yields a string shorter than 4 characters).

The workaround for programmers is simple: don't do that.

What Jacob has advocated, if I recall correctly, is making the result
buffer larger, avoiding undefined behavior for a larger range of
years. (I don't think he's suggested fixing the other cases of
undefined behavior.) I actually agree with his suggestion; unlike the
other cases, the tm_year problem occurs with seemingly valid
arguments.

On the other hand, there's nothing preventing an implementation from
using a larger buffer. Since this would only affect programs that
currently invoke undefined behavior, it would be "the equivalent of
the following algorithm" as far as the standard is concerned.

On the other other hand, if the standard were changed to require a
larger buffer, it would be many years, if ever, before all
implementations conformed an programmers could depend on asctime()
working properly for years after 9999. (This argument applies to any
improvement of this kind; I don't consider it a strong argument.)

Some current implementations actually handle a year overflow by
writing a value that still fits into the result buffer, for example by
writing "****" for the year. Requiring a larger result buffer means
that a user program should invoke asctime() with a buffer larger than
26 characters to avoid undefined behavior. But this isn't really a
problem; it just moves the undefined behavior from the library to the
user's code.

Finally, the buffer overflow isn't asctime()'s only limitation. It's
probably not even its most serious one. It imposes a specific
English-language date format that's incompatible with ISO 8601, and
I've always found the trailing newline character annoying. These
problems *can't* be fixed without breaking existing code. If you want
anything beyond a quick-and-dirty timestamp display, most likely for
debugging, the strftime() function is more useful.

Jacob, I agree that it would be a good idea to fix this particular
buffer overflow. The committee doesn't, and I can see their point.
(Perhaps it would be better to make the behavior
implementation-defined.)

Suggesting that the committee explicitly endorses memory overwrites is
absurd.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Mark McIntyre wrote:

On Sat, 09 Oct 2004 11:45:48 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Mike Wahler wrote:

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr.. .

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,

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.

The poster decides what is on topic here, not you.
You have no right to restrict in any way what I write
or think.

Who cares about your opinion?

You can say "off topic" but I will not go away. Neither
my arguments will. The fact is that no new development is
done in C, and that it should be prived of any discussion of
modern data processing, software engeneering, whatever.

We do not use lists and other shit, that's for pimps.

Of course we know how to insult since we love being a brute
and writing:
ITS FSCKING WELL OFFTOPIC YOU CRETIN.
Ahhh what a viril answer. How profound :-)

This will bring the topic of C and software development
so much further.

Substantive Marck, substantive your contribution.
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.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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*

Jacob, nobody here has the objective of destroying C. I think you
know that. If you've reached that conclusion, I suggest you take as
much time as you need to re-think your assumptions and the reasoning
that led you to it.

comp.lang.c is for discussion of the C programming language as it's
defined. The level of traffic, most of it topical, indicates that
we're in no danger of running out of things to say about it.

comp.std.c is for discussion of the C standard, including proposals
for changing it. If you're unhappy with the way C is currently
defined, that's the place to go to discuss fixing it. In fact, you've
posted there in the past, so I would assume you already know that.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Flash Gordon wrote:

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.

A linked list *complex*?

Wait a minute Flash Gordon (let the rocket continue for
a while alone), and turn on your mind...

How many lists for the different data structures that
you used you have written already?

Let's come back to the facts:

Never did a lists? Now come on, let's stop this nonsense.
You have done probably as much that as me, each time I want
to do a list writing:
DATA *AddToDataList(DATA *item)
{ ... etc... }

void UnlinkFromList(DATA *item)
{ Another etc}

DATA *FindInList(DATA *item)
{ And YET another etc}

Never wrote that Flash Gordon?

Of course maybe you used the library X.

Then, could not be better to have a standard
way of doing easily lists and other stuff?

Of course, there is C++, that is designed to
do that, instead of C that is the old version
that should disappear.

[Mike Wahler]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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*

Jacob, nobody here has the objective of destroying C. I think you
know that. If you've reached that conclusion, I suggest you take as
much time as you need to re-think your assumptions and the reasoning
that led you to it.

comp.lang.c is for discussion of the C programming language as it's
defined. The level of traffic, most of it topical, indicates that
we're in no danger of running out of things to say about it.

comp.std.c is for discussion of the C standard, including proposals
for changing it. If you're unhappy with the way C is currently
defined, that's the place to go to discuss fixing it. In fact, you've
posted there in the past, so I would assume you already know that.

Jacob:

As evidenced by your impressive product, you're obviously
a very bright fellow. This is why I am at a loss to know
why you have such trouble with a concept as simple and
straightforward as the topicality of Usenet fora. Were
you to simply post appropriate group(s), I'm sure your
ideas would be received warmly by many.

-Mike

[jacob navia]

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

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]

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.

It doesn't just stop working in the year 10000. It fails *now* if you
call it with an argument that represents a date in the year 10000 or
later.

Consider a program that reads some sort of timestamps from an external
source, and prints them using asctime(). If one of the timestamps
either has been corrupted or actually represents a date in the far
future (or past), the call to asctime() will invoke undefined
behavior.

It's not all that big a deal; a program can either check the value
before passing it or use strftime() instead (which is much more
versatile anyway). But it is a current problem.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sat, 09 Oct 2004 22:33:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

The deal is that the principle that never a library function should have
memory overwrites is breached.
But the C standard doesn't define how the function is implemented. Read the
wording more carefully and actually think about what you're reading. Do I
really need to quote Dan Pop?
All functions in the library should return an error code if confronted
with invalid inputs.
A similar argument has been used frequently to propose that gets() and
strcpy() be removed from the standard - clearly they're way too dangerous.
However this has to be set against the impact of changing the language as
you propose, since much existing code will now fail or not compile. IF too
much existing code becomes broken then compiler writers won't implement the
new features, because their customers don't want to spend money rewriting
everything. The new Standard is unimplemented, the language stagnates. And
all because someone overzealously tried to update it too much.
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.
And a sensible programmer is aware of his implementation's limits, and
takes care of checking array bounds etc himself.
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.

perhaps the committee felt that pointing out a bug that only arises in the
year 10000 was taking pedantic stupidity to beyond the pale?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Sat, 09 Oct 2004 22:36:51 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Dear "Deafult user"

When all cases are exhausted, there is always the default.

Your answer is by "default":

"crap", "go away" "off topic". Can't you articulate?

Have you ever been on a long journey with tired kids? You know the point in
the journey where the kids are whining "are we nearly there yet?" every 30
seconds, and arguing with their siblings? The point where you pull the car
over and shout into the back "if you lot don't shut up, I'm leaving you all
here in hte middle of Bodmin Moor".

Perhaps, just perhaps, Brian and a lot of the rest of us have heard so much
of your whining, whinging and general silly-boy antics that we've lost
patience.

Give my regards to the Beast.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Sat, 09 Oct 2004 22:43:00 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

The poster decides what is on topic here, not you.
No, the group's charter (if it exists), or the group itself (in the absence
of charter) defines it. An individual poster has absolutely no say at all.
You have no right to restrict in any way what I write or think.
Sure. You have an absolute right to post anything you like into CLC.

But do you see what you're doing? You have lost much respect already, and
are rapidly losing your reputation. Anyone who googles for your name will
see it attached to a long series of rants about how mean everyone is to
you, coupled with many many respected C regulars telling you you're in the
wrong place, talking rubbish etc. Someone trying to get an idea whether to
use your software will have a very poor impression. For goodness' sake get
a grip.
Who cares about your opinion?
Me, obviously!
You can say "off topic" but I will not go away.
Yeah, whatever. You've now become a troll, and I propose to ignore you. If
you post garbage in CLC again I'll post a note advising your readers that
you're well-known for being a troll and for posting inflammatory and
offtopic rubbish.

ITS FSCKING WELL OFFTOPIC YOU CRETIN.

Ahhh what a viril answer. How profound :-)

Since you seem incapable of listening, I tried shouting. You seem incapable
of hearing at all though.
Substantive Marck, substantive your contribution.

Mhm, and your own post, the one I'm replying to, that discussed the C
language in a substantive way?

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[jacob navia]

CBFalconer wrote:

There are myriad libraries (but not standardized libraries)
available for those things.
Well that's my point!
A myriad but none standard, accepted by the language in
the standard library.

Then most people do not have them and it's a pain to
carry different libraries around in different
environments.

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.

Standard C is OK for hash tables, never doubted that.
For length delimited strings I wrote a library around
the existing one but with some compiler
support.

The problem is that the existing language reserves
the brackets, and doesn't allow with a length delimited string:

str[45] = 'e';

but needs
setstring(str,45,'e');

or similar.

Why there is only compiler support for the old data structure?

Caching the string length is inherently more efficient than searching
the trailing zero... but we discussed all that already.

[jacob navia]

Mark McIntyre wrote:

On Sat, 09 Oct 2004 22:33:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

All functions in the library should return an error code if confronted
with invalid inputs.

A similar argument has been used frequently to propose that gets() and
strcpy() be removed from the standard - clearly they're way too dangerous.
However this has to be set against the impact of changing the language as
you propose, since much existing code will now fail or not compile.

Well, that's a good thing why not?
strcpy et al disappear. Microsoft proposed that, and I think they
are right.
IF too
much existing code becomes broken then compiler writers won't implement the
new features, because their customers don't want to spend money rewriting
everything. The new Standard is unimplemented, the language stagnates. And
all because someone overzealously tried to update it too much.

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

[Flash Gordon]

On Sat, 09 Oct 2004 22:50:45 +0200
jacob navia <ja***@jacob.remcomp.fr> wrote:

Flash Gordon wrote:

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.
A linked list *complex*?

Compared to a struct with about half a dozen integers, yes.
Wait a minute Flash Gordon (let the rocket continue for
a while alone), and turn on your mind...

How many lists for the different data structures that
you used you have written already?
Well, outside of the time frame I was referring to there was the time I
implemented linked lists in Fortran 77, then there was the time I
implemented them in TMS320C80 PP assembler.
Let's come back to the facts:

Never did a lists? Now come on, let's stop this nonsense.
You have done probably as much that as me, each time I want
to do a list writing:
DATA *AddToDataList(DATA *item)
{ ... etc... }

void UnlinkFromList(DATA *item)
{ Another etc}

DATA *FindInList(DATA *item)
{ And YET another etc}

Never wrote that Flash Gordon?
I didn't say never, I said that for several years I did not use them. I
also gave examples of projects for which they were not used.

Of course, not having malloc provided on the free standing
implementations I was using was part of it.
Of course maybe you used the library X.
No, I just did not use any linked lists, hash tables or anything of the
sort.

To repeat, if you don't have to do any look ups you don't need hash
tables. If you have fixed amounts of data you don't need linked lists or
any form of dynamic data allocation.
Then, could not be better to have a standard
way of doing easily lists and other stuff?

Of course, there is C++, that is designed to
do that, instead of C that is the old version
that should disappear.

I've only done a very small amount of C++, a lot of C, a lot of Pascal
and a lot of assembler.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Randy Howard]

In article <41***********************@news.wanadoo.fr>, ja***@jacob.remcomp.fr
says...

The assumption that C programming means ignoring data structures
is widespread in this group.
I disagree with that. I think if you look at some of Ben Pfaff's
work, you'll see he obviously doesn't think that way either.
I quoted one of the people that posts the most of such nonsense
You did NOT quote anyone, you posted unattributed text. Quotations
usually give a source if they are to be taken seriously. If you
are afraid of giving the name, then what is the point?
in the thread about containers, a week ago, some people said that they
do not use *any* data structures whatsoever.
And here we get from "some people" to "widespread" somehow. Please
show your steps along that path, I don't see it.
This conservative attitude was repeated when we spoke about operator
overloading.
Operator overloading is a totally different issue.
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.
Note: The committee is not this newsgroup, or vice versa.
Because I want to attack that attitude of blind conservatism where C
is considered a language for unsophisticated brutes :-)
Are we to believe you are a politician? If not, speak plain English
instead of all this dancing around the pin.
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.
Innovation as far as standard C goes belongs in the standards
committee, or in a different language. What you are really upset
about is that you have chosen to *change* the language, without
doing so under a standards banner, OR a different language entirely.
That is precisely the issue as far as I can tell. If you want to
invent a new language called Navia-C or something, go for it. Just
stop calling it C. Navia-C is OT here. You have your own newsgroup,
so be happy and move on.
C is C89. Ahh nostalgie... We were 15 years younger then.
C99 is still-born. Get over it.
C++ introduced many ideas besides this object oriented
stuff. Operator overloading is quite simple conceptually:
It's inherently evil. But, it's in the language. If you want
to discuss C++, you know it's just down the hall. If you want
to discuss lcc, it's just down the hall.
But since most people are convinced that the language is
dead, that is it.

It's not dead. It's pretty much perfect as is, provided you
use it for its intended purpose. It's not a GUI language, it's
not a scripting language, it's not a numerical analysis language.
It's for implementing system level software, and it is remarkably
good at that, in fact, it has no peer in that regard.
--
Randy Howard (2reply remove FOOBAR)
"Show me a young Conservative and I'll show you someone with no heart.
Show me an old Liberal and I'll show you someone with no brains."
-- Winston Churchill

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:
[...]

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.

strlen(NULL) invokes undefined behavior. strlen(x) invokes undefined
behavior if x doesn't point to a null-terminated string. Do you
advocate changing the definition of strlen() so it doesn't invoke
undefined behavior in such cases?

If you want to implement a bulletproof replacement for the C standard
library, go ahead and do it. If it becomes widespread enough, it
might even be incorporated into the next version of the standard.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Guillaume]

> To repeat, if you don't have to do any look ups you don't need hash

tables. If you have fixed amounts of data you don't need linked lists or
any form of dynamic data allocation.

Even for dynamic data structures, you don't need linked lists at all.
I haven't used them in years. Most applications where a linked list
would feel "natural" can be implemented with some kind of dynamic array
instead. Much more efficient. I hate waste.

[Ben Pfaff]

Guillaume <"grsNOSPAM at NOTTHATmail dot com"> writes:

To repeat, if you don't have to do any look ups you don't need hash
tables. If you have fixed amounts of data you don't need linked lists or
any form of dynamic data allocation.

Even for dynamic data structures, you don't need linked lists at all.
I haven't used them in years. Most applications where a linked list
would feel "natural" can be implemented with some kind of dynamic array
instead. Much more efficient. I hate waste.

Dynamic arrays don't allow arbitrary insertions and deletions in
O(1) time. That can also be wasteful in some situations.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[Guillaume]

> Dynamic arrays don't allow arbitrary insertions and deletions in

O(1) time. That can also be wasteful in some situations.

Very true, but in many cases, with a clever implementation, you can
manage to avoid "inserting" items altogether, and instead just append
them. Avoiding doing something computationally expensive is always
a good thing to think about. ;-)

There are many ways of using arrays. You can even implement binary
trees in them.

[CBFalconer]

jacob navia wrote:

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

jacob navia wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Flash Gordon]

On Sat, 09 Oct 2004 19:55:25 -0700
Ben Pfaff <bl*@cs.stanford.edu> wrote:

Guillaume <"grsNOSPAM at NOTTHATmail dot com"> writes:

To repeat, if you don't have to do any look ups you don't need hash
tables. If you have fixed amounts of data you don't need linked
lists or any form of dynamic data allocation.

Even for dynamic data structures, you don't need linked lists at
all.
Agreed.
I haven't used them in years. Most applications where a linked
list would feel "natural" can be implemented with some kind of
dynamic array instead. Much more efficient. I hate waste.

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[RoSsIaCrIiLoIA]

On Sun, 10 Oct 2004 03:38:19 GMT, CBFalconer wrote:

jacob navia wrote:

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]

On Sun, 10 Oct 2004 00:19:39 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

CBFalconer wrote:

There are myriad libraries (but not standardized libraries)
available for those things.

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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Mark McIntyre]

On Sun, 10 Oct 2004 00:25:36 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Mark McIntyre wrote:

A similar argument has been used frequently to propose that gets() and
strcpy() be removed from the standard - clearly they're way too dangerous.
However this has to be set against the impact of changing the language as
you propose, since much existing code will now fail or not compile.
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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[CBFalconer]

Mark McIntyre wrote:

<ja***@jacob.remcomp.fr> wrote:

CBFalconer wrote:

There are myriad libraries (but not standardized libraries)
available for those things.

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

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Joona I Palaste]

Dan Pop <Da*****@cern.ch> scribbled the following:

In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes:

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____________

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 (pa*****@cc.helsinki.fi) ------------- 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]

On Mon, 11 Oct 2004 17:59:14 +0200
jacob navia <ja***@jacob.remcomp.fr> wrote:

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.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.