«

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

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

In article <9d7396c4-2a18-4e75-99b5->,
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?
>
>Tom

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.

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.

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

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

Which is why we have operating systems...

--
Ian Collins

In article <hcps4b$37e$>, jacob navia <> wrote:
>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.

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

On Nov 3, 12:45*pm, gaze...@shell.xmission.com (Kenny McCormack)
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

On Nov 3, 2:21*pm, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <hcps4b$37...@aioe.org>, jacob navia *<j...@nospam.org> wrote:
>
>
>
> >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.

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

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.

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.