Buffer Overruns other C Gotchas -- "Coders at Work"
Casey Hawthorne
people interviewed for the book "Coders at Work" said that C was great
for systems programming by well trained programmers, but that C had
leaked out into the applications area.
For systems programming you do need the access to the machine that C
provides, but for applications programming, you don't need/shouldn't
have such access.
--
Regards,
Casey
Tom St Denis
Kenny McCormack
Does there have to be? Look at Seebs's postings (specifically, the ones
directed at me): Are there any questions there?
P.S. Now there are questions in this thread (count the ? marks).
Are you happy?
P.P.S. Look at any of the postings by RH - no questions there. Ever.
Kiki? Rarely, but sometimes.
Richard Heathfield
<9d7396c4-2a18-4e75...@w19g2000yqk.googlegroups.com>,
Tom St Denis wrote:
Not really, even though he uses the word "question". But there's a
discussion here, certainly. Usenet is not *just* about answering
questions. And it's an interesting and thought-provoking point,
wouldn't you say?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
jacob navia
The deeper problem is that the C users community doesn't even want to a knowledge this problem.
A buffer overrun is *specified* in the code of the C standard itself. The many discussions in this
group or in the similar group comp.lang.c have led to nothing. Endless discussions about trivia but
an enormous BUG specified in the C standard (the asctime() function) will be conserved as it was the
best thing to do.
The code of the asctime() function is written in the C standard as follows:
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;
}
This code will provoke a buffer overflow if the year is, for instance, bigger than 8099.
Nowhere in the standard are the ranges for the year are specified.
In a �Defect Report� filed in 2001, Clive Feather proposed to fix this bug.
The answer of the committee was:
"...asctime() may exhibit undefined behavior... [ snip] .
As always, the range of undefined behavior permitted includes:
Corrupting memory, ... [snip]"
This attitude towards the C language is promoted by all people in the committee apparently since
after dozens of discussions like this one the function (and the code) is still there.
Is it because most people have decided that C should be killed and C++ should be the language of
choice?
Probably, I can't tell.
The same for any evolution of the language. The proposed new C standard to be released somewhen in
2019 or later is a textual copy of the C99 one, including (of course) functions like gets() and
asctime(). The only "concession" of the committee has been to add a footnote where it says that
gets() is deprecated.
A footnote.
Buffer overflows are no more than a footnote worth.
jacob
Ian Collins
Which is why we have operating systems...
--
Ian Collins
Kenny McCormack
>Casey Hawthorne a �crit :
>> I thought of this question, of buffer overruns, after one of the
>> people interviewed for the book "Coders at Work" said that C was great
>> for systems programming by well trained programmers, but that C had
>> leaked out into the applications area.
>>
>> For systems programming you do need the access to the machine that C
>> provides, but for applications programming, you don't need/shouldn't
>> have such access.
>> --
>> Regards,
>> Casey
>
>The deeper problem is that the C users community doesn't even want to a
>knowledge this problem.
>
>A buffer overrun is *specified* in the code of the C standard itself.
>The many discussions in this
>group or in the similar group comp.lang.c have led to nothing. Endless
>discussions about trivia but
>an enormous BUG specified in the C standard (the asctime() function)
>will be conserved as it was the
>best thing to do.
C as a language *is* dead. (for Seebs) That's not to say that there
aren't still systems out there that use it and programmers who earn
their keep programming it, nor that there won't be for decades to come.
But the future is obviously in safer languages, given:
a) The vast improvements in technology (i.e., we can now *afford*
safe languages)
b) The vast reduction in the quality of the American educational
system.
>The code of the asctime() function is written in the C standard as follows:
I like that you always bring up the asctime() function. Very good
example of the state of things.
Tom St Denis
> In
> <9d7396c4-2a18-4e75-99b5-f9086cdc2...@w19g2000yqk.googlegroups.com>,
>
> Tom St Denis wrote:
> > On Nov 3, 12:19 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
> > wrote:
> >> I thought of this question, of buffer overruns, after one of the
> >> people interviewed for the book "Coders at Work" said that C was
> >> great for systems programming by well trained programmers, but that
> >> C had leaked out into the applications area.
>
> >> For systems programming you do need the access to the machine that
> >> C provides, but for applications programming, you don't
> >> need/shouldn't have such access.
>
> > Is there a question here?
>
> Not really, even though he uses the word "question". But there's a
> discussion here, certainly. Usenet is not *just* about answering
> questions. And it's an interesting and thought-provoking point,
> wouldn't you say?
What? That C spilling into userspace applications was a mistake?
You youngins....
Back in the day we wrote applications on bare metal. Heck I'm 27 and
I grew up on writing DOS applications that had direct control over the
VGA, Sound card [or PC speaker whichever] and other devices. If I had
to write everything in say QBASIC or something detached from
successful bit twiddling I'd probably shoot people.
Tom
Tom St Denis
wrote:
> In article <9d7396c4-2a18-4e75-99b5-f9086cdc2...@w19g2000yqk.googlegroups.com>,
> Tom St Denis <t...@iahu.ca> wrote:
>
> >On Nov 3, 12:19 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
> >wrote:
> >> I thought of this question, of buffer overruns, after one of the
> >> people interviewed for the book "Coders at Work" said that C was great
> >> for systems programming by well trained programmers, but that C had
> >> leaked out into the applications area.
>
> >> For systems programming you do need the access to the machine that C
> >> provides, but for applications programming, you don't need/shouldn't
> >> have such access.
>
> >Is there a question here?
>
> >Tom
>
> Does there have to be? Look at Seebs's postings (specifically, the ones
> directed at me): Are there any questions there?
Well he writes "I thought of this question" and nowhere in his post is
a question.
"It's like I was thinking of a C specification issue, then my dog came
over to my lap and I gave it a treat."
Does that make as much sense?
Also the question of whether C is useful for userland applications is
a fairly stupid one. Of course it is. Anyone who has written an
application or two will find the same things that make C successful in
Kernel space applications are useful in userspace.
Tom
Tom St Denis
> In article <hcps4b$37...@aioe.org>, jacob navia <j...@nospam.org> wrote:
>
>
>
> >Casey Hawthorne a écrit :
Really?
tstdenis@photon:~$ cat test.c
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(void)
{
struct tm t;
char *p;
memset(&t, 0, sizeof t);
t.tm_year = 10000;
p = asctime(&t);
printf("%p %s\n", p, p);
return 0;
}
produces:
tstdenis@photon:~$ ./t
0x7fcb834ec540 Sun Jan 0 00:00:00 11900
So not only does it print out a result (by adding 1900 to it) but it
didn't crash.
Maybe the C spec gives an EXAMPLE routine that is meant to be used in
a certain scenario, but it definitely seems like GNU libc is sane.
In short, your opinions are ill founded and totally without merit.
Tom
jacob navia
> Maybe the C spec gives an EXAMPLE routine that is meant to be used in
> a certain scenario, but it definitely seems like GNU libc is sane.
>
Lcc-win doesn't crash either.
I did NOT said that "all implementations of asctime will crash"
What I said is that the code in the text of the C standard
will crash. And I quoted that code. FOR A REASON.
But you are unable to understand what the other person says.
Your conclusion is fixed even before you READ what the other guy
is saying:
> In short, your opinions are ill founded and totally without merit.
>
It is not *my opinion* since if you use the code of the C standard
the buffer that contains 26 positions will NOT support writing
a number with 5 digits!
In short:
You do not read the posts you answer to.
Tom St Denis
> Tom St Denis a écrit :
>
> > Maybe the C spec gives an EXAMPLE routine that is meant to be used in
> > a certain scenario, but it definitely seems like GNU libc is sane.
>
> Lcc-win doesn't crash either.
>
> I did NOT said that "all implementations of asctime will crash"
>
> What I said is that the code in the text of the C standard
> will crash. And I quoted that code. FOR A REASON.
I don't get what the reason is though. If they claim the function
only behaves in a certain range of values how is it ANY DIFFERENT FROM
SAY
char buf[4];
memcpy(buf, "sdklsdhfjkshdfjksdhfjksd", 10);
???
Are you now saying that memcpy is unsafe?
What about
snprintf(buf, 200, "waytooomuchtext");
???
So you're calling asctime with invalid parameters. Maybe your app
should sanity check its inputs?
Tom
jacob navia
> only behaves in a certain range of values how is it ANY DIFFERENT FROM
> SAY
>
> char buf[4];
> memcpy(buf, "sdklsdhfjkshdfjksdhfjksd", 10);
>
> ???
>
> Are you now saying that memcpy is unsafe?
>
> What about
>
> snprintf(buf, 200, "waytooomuchtext");
>
> ???
>
> So you're calling asctime with invalid parameters. Maybe your app
> should sanity check its inputs?
>
> Tom
You still do not read what I said. I said that nowhere in the C standard the ranges
for the year are specified! And that Mr Cleaver in 2001 presented a defect report
precisely because of this. It is all in my post that you refuse to READ!
Your attitude is a further proof of what I said in the first sentence of my post:
"The deeper problem is that the C users community doesn't even want to a acknowledge this problem."
CAN YOU READ?
Then READ my post before answering.
Thanks
Tom St Denis
So this is a flaw in C because? Nowhere have I read that asctime must
be written that way, and in fact glibc doesn't have such a defect.
Maybe I'm missing the part where you had a point.
Tom
Tom St Denis
And in fact the ISO C99 spec says "... using the equivalent of this
function."
Nowhere does it state that you should use that function nor is that
the official version of the function to use. Only that for valid
inputs that's what the behaviour should be.
And really it should be fixed, but it's a really petty thing to base a
"C is useless" argument on.
Tom
jacob navia
> be written that way, and in fact glibc doesn't have such a defect.
>
> Maybe I'm missing the part where you had a point.
>
> Tom
So you think it is a good thing to have code that overflows its buffer in the
C standard itself???
As an "EXAMPLE" ???
I am discussing the flaw in the C standard as an example of C code that provokes
buffer overflows. And as an example of the refusal of many people in the C
community to acknowledge that buffer overflows are a serious thing.
You are proving that this attitude towards buffer overflows is widespread.
Thanks for your help.
jacob
Tom St Denis
> So you think it is a good thing to have code that overflows its buffer in the
> C standard itself???
I didn't say that's a good thing. I didn't say I'd write code like
that. I didn't say it shouldn't be fix.
What I ***DID*** say is that I don't see what this has to do with the
price of tea in china, let alone whether C is a good language for
userspace application development.
I can improperly use any programming language. I don't get what the
point is though. Sure they should fix it. But it doesn't mean I'll
throw away the years of training and experience writing C applications
because some twat writing snippets for a C spec goofed on something.
I don't get you people, form another group if all you want to do is
talk about what's NOT in the C language spec.
I mean, are you a happier, better person for having trolled clc? Does
it fulfill your life? Are you more complete now? I don't get your
motivations. Maybe that's what bugs me the most about trolls. I've
personally come to the realization that my life is finite and I best
use it the way I think I'll enjoy most. Presumably you have similar
goals. So do you enjoy trolling usenet? Is that what makes your life
all that you want it to be?
...
Tom
Keith Thompson
[...]
> Really?
>
> tstdenis@photon:~$ cat test.c
> #include <time.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> struct tm t;
> char *p;
> memset(&t, 0, sizeof t);
> t.tm_year = 10000;
> p = asctime(&t);
> printf("%p %s\n", p, p);
> return 0;
> }
>
> produces:
>
> tstdenis@photon:~$ ./t
> 0x7fcb834ec540 Sun Jan 0 00:00:00 11900
>
> So not only does it print out a result (by adding 1900 to it) but it
> didn't crash.
>
> Maybe the C spec gives an EXAMPLE routine that is meant to be used in
> a certain scenario, but it definitely seems like GNU libc is sane.
Your program's behavior is undefined. On an implementation that
uses the code provided in the standard, asctime will write past
the end of the static "result" string, with unpredictable results.
It happens to behave sanely in your case, just as "i = i++;" might
happen to behave sanely.
And that code is not just an example routine; it's the definition of
the algorithm:
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.
[code snipped]
There is an escape clause for implementers here. An algorithm can
be considered *equivalent* to the one provided if it produces the
same result and behavior in all cases where the behavior of the
provided implementation is defined. In cases where the provided
implementation's behavior is not defined, the implementation can do
anything it likes, including using a bigger buffer. And the glibc
implementation does this; it uses a 114-character buffer rather than
a 26-character buffer, avoiding overflow for any possible arguments.
But it's not *required* to do so.
On another system (Solaris 9), your program dies with a segmentation
fault. This behavior is admittedly unfriendly, but it does not
make the implementation non-conforming. (Note that it does so
whether I compile with Sun's compiler or with gcc; in either case,
it uses Sun's C library, not glibc.)
> In short, your opinions are ill founded and totally without merit.
I agree that jacob's opinions on this matter are ill founded, though
they're not totally without merit.
The behavior of most calls to asctime() is perfectly well defined
(though it's not a behavior I personally find useful; I dislike
the date format it imposes, the addition of a '\n' character, and
the use of a static buffer).
It's possible to invoke asctime() with an argument that makes its
behavior undefined, as you've unintentionally demonstrated. The same
is true of most functions in the C standard library:
char s[5];
strcpy(s, "hello, world");
And yet I don't see jacob claiming that strcpy() itself is "an
enormous BUG specified in the C standard".
The difference, I suppose, is that the circumstances in which
asctime()'s behavior is undefined are a bit more difficult to define
(for example, you can get away with more than 2 digits for tm_sec if
you use fewer than 4 digits for tm_year). On the other hand, those
circumstances are defined, clearly and unambiguously, by the code in
the standard. The definition of asctime() is probably the closest
thing the standard has to a formal specification. The behavior
is rigorously defined in certain cases (all the normal ones), and
clearly undefined in others. Don't call it with unusual values,
and you can depend on it to work as specified.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Gareth Owen
> The code of the asctime() function is written in the C standard as follows:
Everybody knows asctime() is standardised and broken (for some inputs).
Everybody knows gets() is very unsafe and should not be used except in
very limited circumstances.
And yet, every month you bring this up as if it were a great revelation,
and is if this were evidence of some grand cabal to keep the language
from progressing. It's not. It's just evidence that standardisation
bodies move very slowly.
*We all know this*.
Contrary to your assertion, everyone acknowledges it.
Everyone is aware of it.
We just don't care very much.
Sorry, but we don't.
And heres why: asctime() is broken. So I don't use it.
gets() is broken. So I don't use it.
The corkscrew is snapped on my penknife. I don't use that either. But
I still keep the penknife in my car, because the other tools are useful.
Standards documents are not mathematical theorems. A single misstep in
the reasoning does not cause the remainder of the edifice to crumble
into nothingness. A fault in a standard does not condemn the entire
standard to uselessness, and its fundamentally wrong to argue that it
does.
The reason C is static is because in every other domain, there's
something else that does the job well enough. Frequently that's C++,
but sometimes its Perl or Python or sh or Ruby or Fortran ...
There's no point standardising containers for C, because C++ filled that
void 20 years ago and everyone who wants that is using it. It would be
a lot of work, for very little benefit. So no-one is interested in
doing it.
There's no point adding smarter strings to C, because its easier to
write a Perl/Python script to do text processing. It would be a lot of
work, for very little benefit. So no-one is interested in
doing it.
If gets() had been struck from the C99 standard, would anyone have
noticed? Vendors would still have to support it, because of legacy
code. They could warn about its use (as most compilers do already) but
the compilers would be functionally identical as they are now. There's
no practical benefit, so it didn't happen.
There is no real impetus or support for your changes to C in the ways
you suggest, because almost no-one is using C for those purposes.
There's almost no practical benefit. So it won't happen.
Tom St Denis
> Your program's behavior is undefined. On an implementation that
> uses the code provided in the standard, asctime will write past
> the end of the static "result" string, with unpredictable results.
> It happens to behave sanely in your case, just as "i = i++;" might
> happen to behave sanely.
My point more so was that as an instantiation of an environment in
which C may be used it's not always so fubared or dramatic. Ideally,
if the spec says the output can only be 26 chars the Sun platform
should return an appropriate error condition instead of crashing. And
that's THEIR fault for so blindly copying it.
> There is an escape clause for implementers here. An algorithm can
> be considered *equivalent* to the one provided if it produces the
> same result and behavior in all cases where the behavior of the
> provided implementation is defined. In cases where the provided
> implementation's behavior is not defined, the implementation can do
> anything it likes, including using a bigger buffer. And the glibc
> implementation does this; it uses a 114-character buffer rather than
> a 26-character buffer, avoiding overflow for any possible arguments.
> But it's not *required* to do so.
I just read the C99 spec for asctime. Nowhere does it say the buffer
can only be 26 bytes. It describes what the output format must look
like, but never mentions the length. The C code happens to mention
the length in passing but I really consider the C code an example [a
poor one] that produces the desired output format.
> It's possible to invoke asctime() with an argument that makes its
> behavior undefined, as you've unintentionally demonstrated. The same
> is true of most functions in the C standard library:
I haven't read anywhere that says you can't have a year of 11900. I
also don't consider the C code in the spec to define how the algorithm
that produces the output must be written. To me the definition of
asctime() is
---
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
---
The broken C code serves to explain the different textual elements of
the output.
> char s[5];
> strcpy(s, "hello, world");
>
> And yet I don't see jacob claiming that strcpy() itself is "an
> enormous BUG specified in the C standard".
Exactly.
> The difference, I suppose, is that the circumstances in which
> asctime()'s behavior is undefined are a bit more difficult to define
> (for example, you can get away with more than 2 digits for tm_sec if
> you use fewer than 4 digits for tm_year). On the other hand, those
> circumstances are defined, clearly and unambiguously, by the code in
> the standard. The definition of asctime() is probably the closest
> thing the standard has to a formal specification. The behavior
> is rigorously defined in certain cases (all the normal ones), and
> clearly undefined in others. Don't call it with unusual values,
> and you can depend on it to work as specified.
Well I think that's the bigger point here, these C functions have
explicit/implicit assumptions of the inputs.
I haven't read anywhere that explicitly states you can't pass memcpy()
[section 7.21.2.1] NULL as one of the pointers. We just "know" that
because dereferencing a NULL pointer leads to undefined behaviour.
Similarly, by reading the code, assuming you assume that that is the
way your function is implemented it's obvious that you can't have a 5+
digit year. That's an implicit assumption based on the behaviour of
the function based on the description.
And really that's the point. We have people who are not strong
software developers bitching about the fact that they have to sanitize
and properly test their inputs. They'd rather hack together whatever
they can as fast and as incoherently as possible and are pissed that
software development is ACTUALLY REALLY HARD WORK.
Tom
Keith Thompson
[...]
>
> The deeper problem is that the C users community doesn't even want
> to a knowledge this problem.
>
> A buffer overrun is *specified* in the code of the C standard
> itself. The many discussions in this group or in the similar group
> comp.lang.c have led to nothing. Endless discussions about trivia but
> an enormous BUG specified in the C standard (the asctime() function)
> will be conserved as it was the best thing to do.
>
> The code of the asctime() function is written in the C standard as follows:
>
> char *asctime(const struct tm *timeptr)
> {
> }
>
> This code will provoke a buffer overflow if the year is, for
> instance, bigger than 8099. Nowhere in the standard are the ranges
> for the year are specified.
Then how do you know that the limit is 8099?
The range for tm_year is not specified explicitly, and I agree that it
would be helpful if it were. But the range is rigorously specified by
the code provided in the standard. You and I were able to figure it
out.
Consider:
char s[5];
strcpy(s, "hello, world");
Is this a bug in strcpy, or a bug in the code that uses it?
Stealing from Tom St Denis's followup:
struct tm t;
char *p;
memset(&t, 0, sizeof t);
t.tm_year = 10000;
p = asctime(&t);
Is this a bug in asctime, or a bug in the code that uses it?
If your answers are different, can you explain the difference?
Let me be clear. I don't like asctime(). I never use it, other than
in small programs intended to test the functionality of asctime()
itself. I personally think it should be deprecated. But the fact
that its behavior is undefined *given certain arguments* is something
it shares with most other functions in the standard library. And
(the following is just my opinion), given that it's already rigorously
specified, I don't think it would be worth the committee's time to
improve the specification or change the behavior. Why sharpen the
corners on a square wheel?
If you're an implementer, you can provide an asctime() implementation
that doesn't blow up unless you give it a bad pointer (glibc has
done this; I presume you have as well, though I wonder whether yours
is 100% conforming in the corner cases). If you're a programmer,
you can avoid calling asctime() with exotic argument values, or
you can avoid calling asctime() altogether and use the much more
flexible strftime() instead.
Has there been an epidemic of crashing software caused by bad calls
to asctime()? The worst I've seen is a few extraneous newlines in
log files, which had nothing to do with undefined behavior.
It's just not as big a problem as you repeatedly make it out to be.
Ok, if there were a bug in the standard, a clause that implicitly
requires a buffer overflow to occur, that would be a problem worth
fixing, even if it didn't have much effect on the real world.
But that's just not the case here. (It is for gets(), which is
being deprecated, and I'd also be happier if that had been done
sooner or at a quicker pace.)
[...]
> Is it because most people have decided that C should be killed and C++
> should be the language of choice?
Of course not, don't be silly. Do you seriously think that someone
who has decided C should be killed would spend time and money
serving on the C standard committee? You're really not very good
at inferring other people's motivations.
> Probably, I can't tell.
>
> The same for any evolution of the language. The proposed new C
> standard to be released somewhen in 2019 or later is a textual copy
> of the C99 one, including (of course) functions like gets() and
> asctime(). The only "concession" of the committee has been to add a
> footnote where it says that gets() is deprecated.
The proposed new standard is a work in progress. We don't know
how closely it will match the early drafts that have been released
so far. In particular, the changes that have been made so far
are probably not representative of the changes that will be made;
they're just what the committee got to first, and I don't think
they're doing the work in decreasing order of importance.
[A personal note: jacob, I recently sent you a private e-mail message
regarding something you wrote in another thread. I would appreciate
a response, either by e-mail or as a followup in the relevant thread.
Thank you.]
Keith Thompson
> standard the ranges for the year are specified! And that Mr Cleaver
> in 2001 presented a defect report precisely because of this. It is
> all in my post that you refuse to READ!
That was Clive Feather, not Mr Cleaver.
Keith Thompson
>> Your program's behavior is undefined. On an implementation that
>> uses the code provided in the standard, asctime will write past
>> the end of the static "result" string, with unpredictable results.
>> It happens to behave sanely in your case, just as "i = i++;" might
>> happen to behave sanely.
>
> My point more so was that as an instantiation of an environment in
> which C may be used it's not always so fubared or dramatic. Ideally,
> if the spec says the output can only be 26 chars the Sun platform
> should return an appropriate error condition instead of crashing. And
> that's THEIR fault for so blindly copying it.
No, it's your fault for calling asctime with an argument for which its
behavior is undefined. It's a more understandable error than
char s[5];
strcpy(s, "hello, world");
because the valid inputs for asctime() are harder to figure out than
the valid input for strcpy(). But it's still the case that your
program's behavior is undefined, and can blow up on a conforming
implementation.
As it turns out, Sun *didn't* blindly copy the implementation in the
standard. Here's a modified version of your program:
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(void)
{
struct tm t;
char *p;
memset(&t, 0, sizeof t);
t.tm_year = 10000;
p = asctime(&t);
if (p == NULL) {
puts("asctime returned NULL");
}
else {
printf("asctime returned %p --> \"%s\"\n", (void*)p, p);
}
return 0;
}
and its output on Solaris 9:
asctime returned NULL
The standard doesn't specify that asctime returns a null pointer on
error, but it's a reasonable convention -- and it would have helped
you catch your error more quickly than on a glibc-based
implementation.
[...]
> I just read the C99 spec for asctime. Nowhere does it say the buffer
> can only be 26 bytes. It describes what the output format must look
> like, but never mentions the length. The C code happens to mention
> the length in passing but I really consider the C code an example [a
> poor one] that produces the desired output format.
No, the C code is not just an example. It is the definition of the
algorithm.
>> It's possible to invoke asctime() with an argument that makes its
>> behavior undefined, as you've unintentionally demonstrated. The same
>> is true of most functions in the C standard library:
>
> I haven't read anywhere that says you can't have a year of 11900.
Read the algorithm in the standard. Trace through it, and see what
happens if you pass it a year of 11900. It's not stated explicitly
(which is unfortunate), but it's still right there in black and white.
> I
> also don't consider the C code in the spec to define how the algorithm
> that produces the output must be written.
No, but whatever algorithm is used must be equivalent to the one
presented.
> To me the definition of
> asctime() is
>
> ---
> 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
> ---
Only if you stop reading there. The rest of that section isn't
decorative; it means something.
[...]
> Well I think that's the bigger point here, these C functions have
> explicit/implicit assumptions of the inputs.
Yes.
> I haven't read anywhere that explicitly states you can't pass memcpy()
> [section 7.21.2.1] NULL as one of the pointers. We just "know" that
> because dereferencing a NULL pointer leads to undefined behaviour.
C99 7.1.4, Use of library functions:
Each of the following statements applies unless explicitly
stated otherwise in the detailed descriptions that follow:
If an argument to a function has an invalid value (such as
a value outside the domain of the function, or a pointer
outside the address space of the program, or a null pointer,
or a pointer to non-modifiable storage when the corresponding
parameter is not const-qualified) or a type (after promotion)
not expected by a function with variable number of arguments,
the behavior is undefined.
> Similarly, by reading the code, assuming you assume that that is the
> way your function is implemented it's obvious that you can't have a 5+
> digit year. That's an implicit assumption based on the behaviour of
> the function based on the description.
>
> And really that's the point. We have people who are not strong
> software developers bitching about the fact that they have to sanitize
> and properly test their inputs. They'd rather hack together whatever
> they can as fast and as incoherently as possible and are pissed that
> software development is ACTUALLY REALLY HARD WORK.
jacob has strongly criticized the standard's definition of asctime().
Some of his criticisms are overstated; some I actually agree with.
I don't think we can reasonably assume he dislikes asctime()
because using it is "REALLY HARD WORK". Perhaps you were talking
about developers other than jacob, but I don't recall anyone else
complaining about asctime() (well, I have).
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
>jacob navia <ja...@nospam.org> writes:
>[...]
>> You still do not read what I said. I said that nowhere in the C
>> standard the ranges for the year are specified! And that Mr Cleaver
>> in 2001 presented a defect report precisely because of this. It is
>> all in my post that you refuse to READ!
>[...]
>
>That was Clive Feather, not Mr Cleaver.
http://www.politicsforum.org/images/flame_warriors/flame_61.php
crisgoogle
Good grief, here we go again. I just don't get your obsession with
this.
I'm sure something similar to the following has already been pointed
out to
you, but here we go, just for giggles:
If there was sample strcpy code in the standard, either along with the
current
specification, or instead of, that said something like:
char *strcpy(char *s1, const char *s2)
{
size_t i;
while(*s1[i] = *s2[i])
i++;
return s1;
}
... would you be throwing the same fit? If so, why? This code doesn't
do
_anything_ that a conforming implementation can't do, and does
everything
that a conforming implementation must do. I imagine, in fact, that it
does
just about exactly what most implementations actually _do_ do.
If you wouldn't object, why not? By the same criteria that you apply
to
asctime, the standard would have a bug!!
But as you can see, the standard defines exactly the same the language
with
or without that code snippet. Conforming compilers behave exactly the
same
way as long as they're fed code that doesn't exhibit undefined
behhaviour.
Exactly the same bits of code that would be undefined if the standard
_did_
have that code snippet, are in fact undefined under the current state
of affairs.
In short, there are many (many many!) explicit and implicit
opportunities for undefined behaviour in C. asctime has undefined
behaviour
if fed certain inputs, as do lots of other functions and constructs,
but the
inputs that are allowed and give well-defined outputs are clearly (if
not
explicitly) defined by the standard.
Ben Bacarisse
<snip>
> char *strcpy(char *s1, const char *s2)
> {
> size_t i;
>
> while(*s1[i] = *s2[i])
> i++;
>
> return s1;
> }
I think you meant:
char *strcpy(char * restrict s1, const char * restrict s2)
{
size_t i = 0;
while (s1[i] = s2[i])
i++;
return s1;
}
These are all irrelevant to your point, but there may be people
reading this who will be baffled if the code is uncorrected.
<snip>
--
Ben.
crisgoogle
<sigh>
Note to self:
Must remember to engage brain. And to check after changing examples.
Ta.
Richard Heathfield
<59d6e2ad-67ea-49a3...@d10g2000yqh.googlegroups.com>,
Tom St Denis wrote:
> On Nov 3, 12:58 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>>
<9d7396c4-2a18-4e75-99b5-f9086cdc2...@w19g2000yqk.googlegroups.com>,
>>
>> Tom St Denis wrote:
>> > On Nov 3, 12:19 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
>> > wrote:
>> >> I thought of this question, of buffer overruns, after one of the
>> >> people interviewed for the book "Coders at Work" said that C was
>> >> great for systems programming by well trained programmers, but
>> >> that C had leaked out into the applications area.
>>
>> >> For systems programming you do need the access to the machine
>> >> that C provides, but for applications programming, you don't
>> >> need/shouldn't have such access.
>>
>> > Is there a question here?
>>
>> Not really, even though he uses the word "question". But there's a
>> discussion here, certainly. Usenet is not *just* about answering
>> questions. And it's an interesting and thought-provoking point,
>> wouldn't you say?
>
> What? That C spilling into userspace applications was a mistake?
>
> You youngins....
>
> Back in the day we wrote applications on bare metal. Heck I'm 27
...and I was writing software before you were born. So?
> and I grew up on writing DOS applications that had direct control
> over the VGA, Sound card [or PC speaker whichever] and other
> devices.
Sure. It's a debate. Feel free to debate the point! But you may need
better arguments than "because I want to" if you are to persuade the
OP. :-)
> If I
> had to write everything in say QBASIC or something detached from
> successful bit twiddling I'd probably shoot people.
Careful. That's still illegal in some states.
Seebs
>> If I
>> had to write everything in say QBASIC or something detached from
>> successful bit twiddling I'd probably shoot people.
> Careful. That's still illegal in some states.
Remember, the right is to a trial by a jury *of your peers*.
As long as you get all programmers, and you can prove that you were actually
forced to use QBASIC, you should be set.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Joachim Schmitz
> On 2009-11-04, Richard Heathfield <r...@see.sig.invalid> wrote:
>>> If I
>>> had to write everything in say QBASIC or something detached from
>>> successful bit twiddling I'd probably shoot people.
>
>> Careful. That's still illegal in some states.
>
> Remember, the right is to a trial by a jury *of your peers*.
>
> As long as you get all programmers, and you can prove that you were
> actually forced to use QBASIC, you should be set.
There are some states where it is illegal and wehre there is no jury, only a
single judge, who is quite unlikely to be a programmer...
Bye, Jojo
Nick Keighley
> Casey Hawthorne a écrit :
> > I thought of this question, of buffer overruns, after one of the
> > people interviewed for the book "Coders at Work" said that C was great
> > for systems programming by well trained programmers, but that C had
> > leaked out into the applications area.
>
> > For systems programming you do need the access to the machine that C
> > provides, but for applications programming, you don't need/shouldn't
> > have such access.
why do you keep posting this?
> The deeper problem is that the C users community doesn't even want to a knowledge this problem.
if you want a language that doesn't allow buffer overflows then don't
use C
<snip>
James Dow Allen
> On Nov 3, 12:19 pm, Casey Hawthorne <caseyhHAMMER_T...@istar.ca>
> wrote:
>
> > people interviewed for the book "Coders at Work" said that C was great
> > for systems programming by well trained programmers, but that C had
> > leaked out into the applications area.
>
> > For systems programming you do need the access to the machine that C
> > provides, but for applications programming, you don't need/shouldn't
> > have such access.
>
Wow!! Any doubt that bizarre-thinking pedants are roaming in this
group are dispelled.
Or, perhaps I need to read the group's charter. Does it have
a clause based on the Jeopardy game show?
"Comments must be phrased in the form of a question."
James
Tom St Denis
> > Back in the day we wrote applications on bare metal. Heck I'm 27
>
> ...and I was writing software before you were born. So?
Well then ....
> > and I grew up on writing DOS applications that had direct control
> > over the VGA, Sound card [or PC speaker whichever] and other
> > devices.
>
> Sure. It's a debate. Feel free to debate the point! But you may need
> better arguments than "because I want to" if you are to persuade the
> OP. :-)
Because I had to? There weren't video/graphics/sound/modem/etc
drivers back in the day. If I wanted my DOS application to make beeps
and boops I had to poke hardware. Something the OP is probably
unaware of due to age and/or lack of experience.
So the answer to why C "crept" into the userspace is that back in the
day most OSes were blind to hardware [or in the case of a lot of 8-bit
systems there was no OS at all]. So people wrote C applications
around their C code that controlled the hardware.
But to get even more resounding, even today, I'd rather do bit
twiddling like you find in crypto, DSP related codecs, error
correction, etc, in C than something like C# or VB.
Tom
jacob navia
> jacob navia <ja...@nospam.org> writes:
>
>> The code of the asctime() function is written in the C standard as follows:
>
> Everybody knows asctime() is standardised and broken (for some inputs).
> Everybody knows gets() is very unsafe and should not be used except in
> very limited circumstances.
>
> And yet, every month you bring this up as if it were a great revelation,
> and is if this were evidence of some grand cabal to keep the language
> from progressing. It's not. It's just evidence that standardisation
> bodies move very slowly.
>
Dear anonymous coward:
I will go on bringing this every month. Until it is fixed. It is not a great
revelation, it is just that I think that when you want to change things you
have to be stubborn.
> *We all know this*.
>
I know that.
> Contrary to your assertion, everyone acknowledges it.
> Everyone is aware of it.
>
This is not true, since the committee has neither acknowledge it nor
fixed it.
> We just don't care very much.
>
The royal "we". You are so scared that you do not even use your real
name. And... you know what?
I do not care a lot about your opinion either.
Richard Heathfield
> Gareth Owen a �crit :
>> jacob navia <ja...@nospam.org> writes:
>>
>>> The code of the asctime() function is written in the C standard as
>>> follows:
>>
>> Everybody knows asctime() is standardised and broken (for some
>> inputs). Everybody knows gets() is very unsafe and should not be
>> used except in very limited circumstances.
>>
>> And yet, every month you bring this up as if it were a great
>> revelation, and is if this were evidence of some grand cabal to
>> keep the language
>> from progressing. It's not. It's just evidence that
>> standardisation bodies move very slowly.
>>
>
> Dear anonymous coward:
>
> I will go on bringing this every month. Until it is fixed.
That might be a sensible thing to do /if/ this newsgroup had any power
to fix it. But it doesn't.
>> Contrary to your assertion, everyone acknowledges it.
>> Everyone is aware of it.
>>
>
> This is not true, since the committee has neither acknowledge it nor
> fixed it.
That's their problem and your problem (since you choose to make it
so), but it's hard to see how posting to comp.lang.c is going to help
matters. All you are doing is jarring people off. If that's your
goal, well, okay, you're getting there just fine.
> I do not care a lot about your opinion either.
Then tell it to people whose opinions you /do/ care about - the ISO C
Committee are the people to persuade, so go persuade.
Seebs
>> and is if this were evidence of some grand cabal to keep the language
>> from progressing. It's not. It's just evidence that standardisation
>> bodies move very slowly.
> Dear anonymous coward:
I see a name there, I don't see how that's anonymous.
> I will go on bringing this every month. Until it is fixed. It is not a great
> revelation, it is just that I think that when you want to change things you
> have to be stubborn.
You realize that even assuming the committee were fully persuaded that this
needed to change, it would take well more than a year to change it, yes?
> This is not true, since the committee has neither acknowledge it nor
> fixed it.
I have every confidence that this issue will be fixed within two or three
thousand years of when times with five-digit years will be a significant
concern for most people. Possibly sooner.
However, I think it is just mildly possible to imagine that people are
not *especially* concerned about this in the short term.
Kenny McCormack
Seebs <usenet...@seebs.net> wrote:
>On 2009-11-04, jacob navia <ja...@nospam.org> wrote:
>> Gareth Owen a �crit :
>>> And yet, every month you bring this up as if it were a great revelation,
>>> and is if this were evidence of some grand cabal to keep the language
>>> from progressing. It's not. It's just evidence that standardisation
>>> bodies move very slowly.
>
>> Dear anonymous coward:
>
>I see a name there, I don't see how that's anonymous.
A name is a name. Do you think I'm really Kenny MacCormack?
Dik T. Winter
Of course not, you are Nilges.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Kenny McCormack
>In article <hcs18c$au3$2...@news.xmission.com> gaz...@shell.xmission.com
>(Kenny McCormack) writes:
> > In article <slrnhf31qo.mma...@guild.seebs.net>,
> > Seebs <usenet...@seebs.net> wrote:
> > >On 2009-11-04, jacob navia <ja...@nospam.org> wrote:
> > >> Gareth Owen a �crit :
> > >>> And yet, every month you bring this up as if it were a great
> > >>> revelation, and is if this were evidence of some grand cabal to
> > >>> keep the language from progressing. It's not. It's just
> > >>> evidence that standardisation bodies move very slowly.
> > >
> > >> Dear anonymous coward:
> > >
> > >I see a name there, I don't see how that's anonymous.
> >
> > A name is a name. Do you think I'm really Kenny MacCormack?
>
>Of course not, you are Nilges.
I think I am Han.
Keith Thompson
Did you notice that the original article begins with "I thought of
this question", and then doesn't ask a question?
Keith Thompson
> Gareth Owen a écrit :
[snip]
>
> Dear anonymous coward:
[snip]
> The royal "we". You are so scared that you do not even use your real
> name. And... you know what?
>
> I do not care a lot about your opinion either.
jacob, do you have some reason to believe that Gareth Owen isn't his
real name?
Also, I posted a rather lengthy followup in this thread. If you
intend to ignore what I have to say on the topic of asctime(),
please let me know so I can stop wasting my time.
lawrenc...@siemens.com
>
> A buffer overrun is *specified* in the code of the C standard itself.
For the gazillionth time, a *potential* buffer overrun is specified.
Any code that would trigger that buffer overrun is *incorrect*.
> The many discussions in this group or in the similar group
> comp.lang.c have led to nothing.
Strangely enough, all the shouting I've done at my TV set hasn't
improved the quality of the shows, either.
> This code will provoke a buffer overflow if the year is, for instance,
> bigger than 8099.
>
> Nowhere in the standard are the ranges for the year are specified.
The range is specified by the code that you keep insisting is broken.
However, the latest draft (N1401) now spells it out explicitly (and more
restrictively):
If any of the fields of the broken-down time contain values that
are outside their normal ranges, the behavior of the asctime
function is undefined. Likewise, if the calculated year exceeds
four digits or is less than the year 1000, the behavior is
undefined.
You'll be happy to know that the committee just voted (unanimously, as
it turns out) to remove gets() from the draft as well.
So what are you going to complain about now?
--
Larry Jones
Please tell me I'm adopted. -- Calvin
Seebs
> For the gazillionth time, a *potential* buffer overrun is specified.
> Any code that would trigger that buffer overrun is *incorrect*.
Perhaps true now. It's not totally obvious to me that this was true of,
say, C99 -- there, I don't see anything wrong with a year 10K.
> You'll be happy to know that the committee just voted (unanimously, as
> it turns out) to remove gets() from the draft as well.
Yayyyy!
Kenny McCormack
Keith "Kiki" Thompson <ks...@mib.org> wrote:
...
>Did you notice that the original article begins with "I thought of
>this question", and then doesn't ask a question?
The word "question" has a broader and deeper meaning (in English or any
other languguage) than simple "high school exam" level Q&A. I.e., not
all uses of the word correspond to the simplistic notion
(Q: "What is 2+2?" A:"4") that appeals to the regs of this ng.
Think of it this way: The general question facing C programmers today is
well known, but it doesn't fit the above model. The general question is
"Can C survive? - in the modern computing world - in the face of
competition from obviously safer languages" (with the subtext of "Can I
continue to earn my keep doing it?")
That's what I took to be the implied question in the OP's mind. It was
not necessary for him to state it explicitly.
jacob navia
> jacob navia <ja...@nospam.org> wrote:
>> A buffer overrun is *specified* in the code of the C standard itself.
>
> For the gazillionth time, a *potential* buffer overrun is specified.
> Any code that would trigger that buffer overrun is *incorrect*.
>
>> The many discussions in this group or in the similar group
>> comp.lang.c have led to nothing.
>
> Strangely enough, all the shouting I've done at my TV set hasn't
> improved the quality of the shows, either.
>
>> This code will provoke a buffer overflow if the year is, for instance,
>> bigger than 8099.
>>
>> Nowhere in the standard are the ranges for the year are specified.
>
> The range is specified by the code that you keep insisting is broken.
> However, the latest draft (N1401) now spells it out explicitly (and more
> restrictively):
>
> If any of the fields of the broken-down time contain values that
> are outside their normal ranges, the behavior of the asctime
> function is undefined. Likewise, if the calculated year exceeds
> four digits or is less than the year 1000, the behavior is
> undefined.
>
Well, this is REALLY A GOOD NEWS!!!!!
I did not see any announcements for N1401 in comp.std.c, so I wasn't aware of its
existence. I am REALLY glad the committee has at last changed and that
all this discussions weren't just wasted time. I was getting REALLY depressed.
Thanks a lot to you for this great news.
> You'll be happy to know that the committee just voted (unanimously, as
> it turns out) to remove gets() from the draft as well.
>
YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is at last some real progress.
> So what are you going to complain about now?
Dam!!!
I lost my best complaining points!
:-)
Keith Thompson
> On 2009-11-04, lawrenc...@siemens.com <lawrenc...@siemens.com> wrote:
>> For the gazillionth time, a *potential* buffer overrun is specified.
>> Any code that would trigger that buffer overrun is *incorrect*.
>
> Perhaps true now. It's not totally obvious to me that this was true of,
> say, C99 -- there, I don't see anything wrong with a year 10K.
I believe it is. A year 10K causes the behavior of the algorithm
presented in the standard to be undefined. C99 is IMHO insufficiently
explicit about this, but I see no ambiguity.
>> it turns out) to remove gets() from the draft as well.
>
> Yayyyy!
Woohoo!
Keith Thompson
[...]
> The range is specified by the code that you keep insisting is broken.
> However, the latest draft (N1401) now spells it out explicitly (and more
> restrictively):
>
> If any of the fields of the broken-down time contain values that
> are outside their normal ranges, the behavior of the asctime
> function is undefined. Likewise, if the calculated year exceeds
> four digits or is less than the year 1000, the behavior is
> undefined.
I had a copy of N1401, but I hadn't noticed that.
Actually, it says "the behavior of asctime function is undefined";
there's a missing "the", at least in my PDF copy.
Of course this makes some extremely obscure asctime() calls whose
behavior was previously defined undefined (for example, tm_sec==99),
but that's fine with me. That should probably be mentioned in a list
of changes from C99. (Perhaps it already is; I haven't checked.)
Another minor suggestion: the current description is internally
inconsistent. It says the result is computed "using the equivalent
of the following algorithm", and then says that the behavior is
undefined in cases where the algorithm has well defined behavior.
It's obviously the intent that the description is a further
restriction on the algorithm, but it could be stated more clearly.
Suggestion:
... using the equivalent of the following algorithm:
[...]
except that if any of the fields ...
My personal preference would be to deprecate asctime() and ctime(),
(strftime() is more flexible and doesn't impose an ugly output
format) but that's not a big deal.
I've never thought the problems with asctime() were that serious,
but this change is a substantial improvement. Thanks!
A couple of non-issues:
There is no "normal range" for tm_isdst; that's not a problem, since
there are no values for tm_isdst that cause actime() to misbehave.
(There's also no "normal range" for tm_year, but of course that's
covered explicitly.)
ctime() can invoke UB for certain time_t values (on systems where
time_t's range is sufficiently wide), but that's covered by the
statement that it's equivalent to asctime(localtime(timer)).
> You'll be happy to know that the committee just voted (unanimously, as
> it turns out) to remove gets() from the draft as well.
Huzzah!
[...]
lawrenc...@siemens.com
>
> Actually, it says "the behavior of asctime function is undefined";
> there's a missing "the", at least in my PDF copy.
Oops. At least I spelled "September" correctly this time. :-)
Thanks for the correction.
--
Larry Jones
Ha! Wild zontars couldn't drag that information out of me! Do your worst!
-- Calvin
Noob
> In article <hcs18c$au3$2...@news.xmission.com> gaz...@shell.xmission.com (Kenny McCormack) wrote:
>
>> A name is a name. Do you think I'm really Kenny MacCormack?
Dude, you can't even get that right.
http://en.wikipedia.org/wiki/Kenny_McCormick
> Of course not, you are Nilges.
I don't think so. Little Kenny has been around far longer.
Richard Heathfield
I don't think so. Nilges goes back well over a decade.
Seebs
> I don't think so. Nilges goes back well over a decade.
They don't seem very similar to me. I don't particularly agree with Kenny's
premises, but he is coherent if you grant them for the sake of argument.