lcc-win32

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

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


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.

 

[jacob navia]

Oh, grow up you silly silly person.




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.

 

[Keith Thompson]

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

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]

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]

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.

 

[Mark McIntyre]

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]

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]

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.

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?

 

[jacob navia]

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]

On Sat, 09 Oct 2004 22:33:34 +0200, in comp.lang.c , jacob navia




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]

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.

 

[Randy Howard]

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.

 

[Keith Thompson]

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.

 

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

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.

 

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

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.