lcc-win32

[Mike Wahler]

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

And that will magically delete the object code for
the list, huh?

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

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 the actual code for those functions still resides on my
disk.

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

'Scuse me while I blow my nose.

using only integer operations
and table lookups.


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

I use them extensively, in virtually every nontrivial program.
These libraries are not standard. This bothers me not at all.

I would like just a standard lib, i.e. that has the same
interface in all implementations.

Then create one. If you want standardization, approach standards
bodies. This newsgroup is not such a body.

A first step would be to
review those libs and put the best in the FAQ.

Doesn't the FAQ already have links to various tools and resources
such as libraries?

The FAQ could be used as a repository of programs

Then it would cease to be a FAQ, it would be something else.

that give
a common interface, is well tested and proposed as a standard lib.

Make all the proposals you like. But wouldn't it be more productive
to posit your ideas to those who write standards, instead of the
population of comp.lang.c, who are here to discuss the existing
C language?

Programs could be more portable if we extend standard C.

Perhaps. Go to comp.std.c and make your proposals. At least
there, they'd be topical.

Standards enhance the software by increasing portability.

That is one of many benefits of standardization.

-Mike

 

[Keith Thompson]

On Mon, 11 Oct 2004 19:36:13 +0200


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.

Agreed, but an implementation is allowed to use the exact C code
presented in the standard to implement the asctime() function, which
means that a call to asctime() representing a year outside the range
-999 .. 9999 invokes undefined behavior. An implementation is
allowed, but not required, to use a larger buffer, causing the effect
of the undefined behavior to be friendlier.

As a programmer, it doesn't help me to know that an implementation
*may* implement asctime() so it doesn't blow up given an out-of-range
argument. I still need to avoid calling asctime() with values outside
the supported range. This is a burden, but a trivial one.

 

[CBFalconer]

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.

You seem to be implying the impossibility of creating a library
with your system, together with the impossibility of retaining
source code files. Maybe an examination of snippets.com (or is it
..org??) would help.

Maybe you should create singly linked lists around the definition:

typedef struct sllist {
struct sllist *next;
void *data;
} sllist, *sllistp;

Which will allow you to separate list handling from list use.

 

[Flash Gordon]

Agreed, but an implementation is allowed to use the exact C code
presented in the standard to implement the asctime() function, which
means that a call to asctime() representing a year outside the range
-999 .. 9999 invokes undefined behavior. An implementation is
allowed, but not required, to use a larger buffer, causing the effect
of the undefined behavior to be friendlier.

As a programmer, it doesn't help me to know that an implementation
*may* implement asctime() so it doesn't blow up given an out-of-range
argument. I still need to avoid calling asctime() with values outside
the supported range. This is a burden, but a trivial one.

Agreed. I was just pointing out that the standard does not impose a
buffer overrun vulnerability, it merely allows an implementation to have
one.

Personally I would use strftime (as someone else mentioned) and ignore
asctime, it's a much friendlier function. I would also ignore ctime.
strftime also has the advantage that (quoting from 7.23.3.5 in N869) "If
any of the specified values is outside the normal range, the characters
stored are unspecified." so even with invalid data you don't get
undefined behaviour. However, if there is any possibility of out of
range data my opinion is that this still needs to be handled by the
programmer, since the unspecified characters written may not be the ones
you want.

 

[Richard Bos]

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.

No, it ain't. It would be trolling if it were done to provoke us, but I
don't believe this is the case. It appears that Jacob really _does_
think that adding dead weight makes his implementation better than its
ancestor. It also appears that Jacob really does think that it's quite
alright to talk about his grab-box any place where it's even vaguely
related to the topic. This does make him a bit of a kook, and somewhat
sad, really, but a troll is a different kind of creature.

Richard

 

[Christopher Benson-Manica]

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.

I may be venturing into comp.std.c territory here, but I'd be
interested in seeing something like the HTML standards implemented -
user agents change gradually to match the W3C specifications, so the
language evolves while allowing old markup to be used for a long time.
It's just an idle (and probably unoriginal) thought...

 

[Dan Pop]

I may be venturing into comp.std.c territory here, but I'd be
interested in seeing something like the HTML standards implemented -
user agents change gradually to match the W3C specifications, so the
language evolves while allowing old markup to be used for a long time.
It's just an idle (and probably unoriginal) thought...

It is not realistically feasible to put everything useful in *one*
standard. The C standard should provide an infrastructure upon which
other standards could build on. One should complain (and actually do
something more constructive than that) about the lack of such standards
and not about the kitchen sink missing from the C standard.

Furthermore, such standards should provide multiple language interfaces
to the respective libraries, whenever possible.

Dan

 

[Mark McIntyre]

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

Sure, that'll remove the names, and with a badly optimised compiler it'll
reduce the link size. But the size of the implementation on disk isn't
affected.

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.

Then propose one to comp.std.c, and see how you get on

A first step would be to
review those libs and put the best in the FAQ.

This thread aside, this is not an FAQ so it has little or no place in the
FAQ.

 

[Old Wolf]

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).
So there is a small amount of seriousness.

 

[Dan Pop]

I discovered a buffer
overflow in the code of the asctime function, printed in the standard.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).

You need to get root access in order to be able to set the clock to the
year 10000 (assuming that the system supports such dates in the first
place).

Dan

 

[jacob navia]

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.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).
So there is a small amount of seriousness.

There is no need to set the clock.
Just call asctime with a year of 10000
You fill a structure tm, with say year 10000, month 665, etc, and call
asctime.

No need to set the clock.

 

[Dan Pop]

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.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).
So there is a small amount of seriousness.

There is no need to set the clock.
Just call asctime with a year of 10000
You fill a structure tm, with say year 10000, month 665, etc, and call
asctime.

No need to set the clock.

You missed the point. The idea is not to compromise *your* program, but
another program, running with root privileges, whose code you cannot
control. If that program uses the asctime function with the current date
as an argument, you can compromise it by setting the system date to
year 10k. If you have enough information about a lot of things,
you may be able to control the actual behaviour of the program to
your advantage. In theory, at least.

I have pointed out elsethread the flaw in the reasoning.

Dan

 

[CBFalconer]

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.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).

You need to get root access in order to be able to set the clock to
the year 10000 (assuming that the system supports such dates in the
first place).

Where is "root access" specified in any C standard?

 

[Mark McIntyre]

Just call asctime with a year of 10000
You fill a structure tm, with say year 10000, month 665, etc, and call
asctime.

But as you already know, this can be trivially defended against by the same
kind of technique that any competent programmer should be well versed in
with a host of other functions which you seem not to find offensive.

As far as I'm concerned, all you're showing is that you're obsessing about
a trivium because you think it makes you look 'clever' . Bzzzt. Wrong.

Next.

 

[Michael Mair]

Cheerio,

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.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).

You need to get root access in order to be able to set the clock to
the year 10000 (assuming that the system supports such dates in the
first place).

Where is "root access" specified in any C standard?

Ah, come on. You won't find the word "leak" in the standard
but we are often talking about memory leaks and you won't find
"overflow" but in the integer and floating point arithmetic
context and still we are talking about buffer overflows.

Of course an exploit is a system and implementation dependent
thing. Otherwise, certain M$ products should not have problems
with buffer overflows as they are not defined by the C standard.
And as root access is not defined, we all live in pink clouds
and are happy... ;-)


--Michael

 

[jacob navia]

Besides the security considerations, there is the
principle of library functions returning known values for
all possible inputs.

asctime should be correctly specified, setting ERANGE when
one of its inputs is out of range, that's all.

Recognizing this is beyond some people here, that
like polemic but not any discussion about the issues at hand.

jacob

 

[Keith Thompson]

Besides the security considerations, there is the
principle of library functions returning known values for
all possible inputs.

The C standard library does not follow this principle. Making it do
so would require a major redesign, and would break existing code;
that's just not going to happen. A more robust replacement for the C
standard library might be an interesting idea; by all means, feel free
to implement it.

I've asked you before what you think strlen(NULL) should do; you never
answered.

asctime should be correctly specified, setting ERANGE when
one of its inputs is out of range, that's all.

In a previous article, I listed a number of circumstances in which the
sample implementation of asctime() can invoke undefined behavior.
Should it detect all of them? What about asctime(NULL)? What about
asctime(random_pointer_value)?

The behavior of asctime with an argument denoting a value after the
year 9999 is merely one of many instances of undefined behavior in the
standard library. I actually agree that it should be fixed, but it's
not that big a deal. Programmers just need to be careful.

If you want a bulletproof language that cleanly handles all possible
errors, I submit that C is not the language for you.

Recognizing this is beyond some people here, that
like polemic but not any discussion about the issues at hand.

None of this is "beyond" us. We understand what you're saying; we
just don't necessarily agree, and we wish you'd discuss it where it's
actually topical.

 

[jacob navia]

I've asked you before what you think strlen(NULL) should do; you never
answered.

Should return zero and set errno to EDOM. Zero would make NULL
identical to the empty string, what is consistent with the
usage many applications make of NULL.

The domain of strlen is the set of non-empty strings. Hence, EDOM
is a correct indicator.

The behavior now (just undefined) allows for the above implementation,
Specifying this would make the library more consistent.

The same could be done for many other functions that do not expect
NULL:
fopen(NULL,NULL) --> NULL errno = EDOM
fopen(NULL,"wb") --> NULL errno = EDOM
etc.

In a previous article, I listed a number of circumstances in which the
sample implementation of asctime() can invoke undefined behavior.
Should it detect all of them? What about asctime(NULL)? What about
asctime(random_pointer_value)?

The behavior of asctime with an argument denoting a value after the
year 9999 is merely one of many instances of undefined behavior in the
standard library. I actually agree that it should be fixed, but it's
not that big a deal. Programmers just need to be careful.

The problem is made worst when the standard publishes code
like
char buffer[26];

Why did they specify asctime with all this detail?

There are many other functions where code would have been useful.
No, they had to publish code that overflows and crashes at
the slightest error.

If you want a bulletproof language that cleanly handles all possible
errors, I submit that C is not the language for you.

I strive in my programs to write code as bulletproof as possible.
This can be done in C.

If C is to be understood as a language where "anything goes", we
have to reach the conclusion that C is to be avoided at all
costs in any serious application.

Defensive programming and error analysis are part of a system
design, and it has to be done. C is no exception: programs
should be robust and handle gracefully incorrect inputs
without blowing up.

None of this is "beyond" us. We understand what you're saying; we
just don't necessarily agree, and we wish you'd discuss it where it's
actually topical.

The discussion in comp.std.c didn't lead to anything.
The gets function is still there, trigraphs are still there,
the general attitude is that C should avoid any change
and go into obsolescence.

Most of the people in comp.std.c and here think that
C++ is the way to go, hence, C should stay where it is
and disappear.

 

[Dan Pop]

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.

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?

A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).

You need to get root access in order to be able to set the clock to
the year 10000 (assuming that the system supports such dates in the
first place).

Where is "root access" specified in any C standard?

Where is the setting the clock procedure described in the C standard?

Engage your brain, next time!

Dan

 

[Dan Pop]

Besides the security considerations, there is the
principle of library functions returning known values for
all possible inputs.

There is no such principle for the C standard library. strlen(NULL)
invokes undefined behaviour. Ditto for strlen((char *)123).

Calling a <time.h> function with a date that cannot be represented by
time_t invokes undefined behaviour.

Dan