Free C Compiler on Windows

[Keith Thompson]

You persist in misunderstanding -- that is *not* "the code of the
asctime() function", it is an illustration of the algorithm to be used
by the asctime() function. Yes, it happens to look a lot like C code
since that was the simplest way to describe the algorithm, but no where
is there even a hint that implementations should use that code verbatim.

Yes, but implementations are certainly allowed to use that code
verbatim, and one could argue that there's not much reason not to do
so.

Because asctime() is defined by an algorithm expressed in C, its
behavior is defined by that C code. In particular, its behavior is
well defined in some very odd (and not very useful) cases, and
undefined in some cases that could have been caught as errors. Those
cases can be determined unambiguously by examining the code, but
they're not stated at all clearly.

In my opinion, asctime() is irredeemably ugly; perhaps deprecating it
in favor of strftime() would be better than trying to "fix" it.

[...]

 

[jacob navia]

You persist in misunderstanding -- that is *not* "the code of the
asctime() function", it is an illustration of the algorithm to be used
by the asctime() function.

GREAT!

In that "illustration" then, we have a buffer overflow. That is part of
the specs or what?

> Yes, it happens to look a lot like C code
since that was the simplest way to describe the algorithm, but no where
is there even a hint that implementations should use that code verbatim.

Why show code with buffer overflows?

No, the existing standard can be reaffirmed if no changes are deemed
necessary.

That is what the first proposal looks like. gets() is STILL there!
asctime() buffer overflow in the "illustration" is still there.

There are almost NO changes. The language is completely frozen in the
bugs that this people persist on perpetuating.

 

[lawrence.jones]

In that "illustration" then, we have a buffer overflow. That is part of
the specs or what?

Yes, it is part of the spec: certain input values result in undefined
behavior, so correct programs must avoid such inputs.

That is what the first proposal looks like. gets() is STILL there!
asctime() buffer overflow in the "illustration" is still there.

There are almost NO changes. The language is completely frozen in the
bugs that this people persist on perpetuating.

The document you're referring to is *not* a "first proposal" -- it's a
working document that the committee has just started making changes to.
There will be many more working documents (there's already a second one)
with many more changes before the committee produces a first proposal
for a new standard (which is called a Committee Draft [CD] in ISO-speak).

 

[Keith Thompson]

The document you're referring to is *not* a "first proposal" -- it's a
working document that the committee has just started making changes to.

Yes, we've tried to explain this to jacob multiple times.

There will be many more working documents (there's already a second one)

Would that be http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?

I see that the file is about a third the size of the previous draft,
n1336.pdf; do you know why?

with many more changes before the committee produces a first proposal
for a new standard (which is called a Committee Draft [CD] in ISO-speak).

 

[jacob navia]

Would that be http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?

From that document:
----------------------------------------------------------------------
7.19.7.7 The gets function
Synopsis
1 #include <stdio.h>
char *gets(char *s);
Description
2 The gets function reads characters from the input stream pointed to by
stdin, into the array pointed to by s, until end-of-file is encountered
or a new-line character is read.
Any new-line character is discarded, and a null character is written
immediately after the last character read into the array.
Returns
3 The gets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is returned.
If a read error occurs during the operation, the array contents are
indeterminate and a null pointer is returned.
Forward references: future library directions (7.27.9).

 

[Keith Thompson]

From that document:
----------------------------------------------------------------------
7.19.7.7 The gets function
Synopsis
1 #include <stdio.h>
char *gets(char *s);
Description
2 The gets function reads characters from the input stream pointed to
by stdin, into the array pointed to by s, until end-of-file is
encountered or a new-line character is read.
Any new-line character is discarded, and a null character is written
immediately after the last character read into the array.
Returns
3 The gets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is
returned. If a read error occurs during the operation, the array
contents are
indeterminate and a null pointer is returned.
Forward references: future library directions (7.27.9).
------------------------------------------------------------------------

Right. This has not changed from the C99 standard, to N1256 (C99 plus
TC1, TC2, and TC3), to N1336 (the first preliminary C201X draft), to
N1362 (the second preliminary C201X draft).

Note that all these documents other than the original C99 standard
have the following in the "Future library directions" section:

The gets function is obsolescent, and is deprecated.

So what exactly is your point, jacob? As Larry Jones recently said in
reference to N1336 (and I'm sure this applies equally to N1362):

| The document you're referring to is *not* a "first proposal" -- it's a
| working document that the committee has just started making changes to.

Whatever changes might be made with regard to gets(), the committee
just hasn't gotten to them yet.

 

[jacob navia]

Right. This has not changed from the C99 standard, to N1256 (C99 plus
TC1, TC2, and TC3), to N1336 (the first preliminary C201X draft), to
N1362 (the second preliminary C201X draft).

Note that all these documents other than the original C99 standard
have the following in the "Future library directions" section:

The gets function is obsolescent, and is deprecated.

So what exactly is your point, jacob? As Larry Jones recently said in
reference to N1336 (and I'm sure this applies equally to N1362):

| The document you're referring to is *not* a "first proposal" -- it's a
| working document that the committee has just started making changes to.

Whatever changes might be made with regard to gets(), the committee
just hasn't gotten to them yet.

So, after all those discussions in comp.std.c, after all those documents
everywhere, after the thousands of pages explaining why gets() is an
error they STILL DO NOT ACKNOWLEDGE that gets() should go.

Great. And now you ask

"What is your point jacob"?

I said:
<quote>
The language is completely frozen in the bugs that this people persist
on perpetuating.
<end quote>

And no, I still do not see why this function will REMAIN in the language
until 2020 or later!

 

[Lew Pitcher]

Keith Thompson wrote:
Would that be
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1362.pdf?
From that document:
----------------------------------------------------------------------
7.19.7.7 The gets function
Synopsis
1 #include <stdio.h>
char *gets(char *s);
Description
2 The gets function reads characters from the input stream pointed to
by stdin, into the array pointed to by s, until end-of-file is
encountered or a new-line character is read.
Any new-line character is discarded, and a null character is written
immediately after the last character read into the array.
Returns
3 The gets function returns s if successful. If end-of-file is
encountered and no characters have been read into the array, the
contents of the array remain unchanged and a null pointer is
returned. If a read error occurs during the operation, the array
contents are
indeterminate and a null pointer is returned.
Forward references: future library directions (7.27.9).
------------------------------------------------------------------------

Right. This has not changed from the C99 standard, to N1256 (C99 plus [snip]
Whatever changes might be made with regard to gets(), the committee
just hasn't gotten to them yet.

So, after all those discussions in comp.std.c, after all those documents
everywhere, after the thousands of pages explaining why gets() is an
error they STILL DO NOT ACKNOWLEDGE that gets() should go.

I don't agree.

You would be correct in that assertion *if this were the published
standard*, but it isn't. It is a /working document/; a draft that is
acknowledged by the authors to be incomplete and still under development.

Boy, you /really/ don't get the "standardization process", do you?

[snip]

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[jacob navia]

I don't agree.

You would be correct in that assertion *if this were the published
standard*, but it isn't. It is a /working document/; a draft that is
acknowledged by the authors to be incomplete and still under development.

Boy, you /really/ don't get the "standardization process", do you?

[snip]

And how many YEARS will it take for those people to realize that gets()
is not really a good idea? It is already one year more or less since
they started this isn't it?

Boy, I surely do not get the "standardization process". I just do not
get it why it is SO difficult to just

(1) Select the text that defines the gets() function
(2) Press the "delete" key
(3) Save

Boy, I do not get it. I am too stupid for that. I need a freshman class
in the "standardization process".

Lesson (1)

Bugs aren't bugs

Lesson (2)

If you find a bug or a misfeature, rule (1) applies.

 

[Lew Pitcher]

I don't agree.

You would be correct in that assertion *if this were the published
standard*, but it isn't. It is a /working document/; a draft that is
acknowledged by the authors to be incomplete and still under development.

Boy, you /really/ don't get the "standardization process", do you?

[snip]

And how many YEARS will it take for those people to realize that gets()
is not really a good idea?

Probably about as long as it has taken for developers to realize that
void main() { ... }
is not a good idea.

The problem is, we still see programmers code void main(), even though the
standard says otherwise. You *will not* rid the world of gets() simply by
removing it from the standard.

To answer your question seriously: the standards body probably *already
understands that gets() has serious flaws*. They simply haven't made a
change to their working document yet.

It is already one year more or less since they started this isn't it?

So? You imagine that international standards are written overnight? Not by a
long shot.

[snip]

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Bartc]

They included gets() in the next version of the standard, a proposal
presented some months ago. ALl they would do is to add a tiny footnote
saying that that function is "obsolescent". Getting rid of it would be
too much change for the standard.

Yes why is it necessary to have gets() as part of the standard library when
it's so easy to create your own:

#include <stdio.h>
#include <limits.h>

char* gets(char *s){
char *t;

t=fgets(s,LONG_MAX,stdin);
if (t==NULL) return NULL;

while (*t!='\n') ++t;
*t=0;
return s;
}

 

[Kaz Kylheku]

Boy, I surely do not get the "standardization process". I just do not
get it why it is SO difficult to just

(1) Select the text that defines the gets() function
(2) Press the "delete" key
(3) Save

Agreed. The gets function does not require a fscking obsolescence phase. Just
delete it! No mention of it anywhere. Implementations then have to remove gets
from their <stdio.h> header, and allow programs to use it as a name with
external linkage. This bold move can be accomplished in one revision.

 

[James Kuyper]

That is what the first proposal looks like. gets() is STILL there!
asctime() buffer overflow in the "illustration" is still there.

....
The document you're referring to is *not* a "first proposal" -- it's a
working document that the committee has just started making changes to.
There will be many more working documents (there's already a second one)
with many more changes before the committee produces a first proposal
for a new standard (which is called a Committee Draft [CD] in ISO-speak).

Let me ask the questions that jacob seems incapable of asking:

If the committee were planning to make some changes to the next version
of the standard to deal with gets() and asctime(), at what point in the
process could jacob reasonably expect to find a document reflecting
those planned changes? Can you estimate how soon that point will be
reached?

At what point in the process could jacob reasonably assume that the
absence of any changes means that the committee isn't planning to make
any? Can you estimate when that point will be reached?

Finally, in the unlikely event that jacob ever decides to do something
more productive about these issues than complain in this newsgroup about
how stupid he thinks the committee is, what should that something be,
and what is the deadline for doing it in time for this version of the
standard?

 

[Ben Bacarisse]

Yes why is it necessary to have gets() as part of the standard library
when it's so easy to create your own:

#include <stdio.h>
#include <limits.h>

char* gets(char *s){
char *t;

t=fgets(s,LONG_MAX,stdin);
if (t==NULL) return NULL;

while (*t!='\n') ++t;
*t=0;
return s;
}

That is marginally worse than gets since it has undefined behaviour
when EOF is not immediately preceded by '\n'. In that situation fgets
reads some characters (that may well fit in the user's buffer) but
there is no newline to find.

In the spirit of spelling corrections, here is mine so you can find
the bug I will not doubt leave in it:

/* Don't try this at home. */

char *gets(char *s)
{
char *cp = s;
int c;
while ((c = getchar()) != EOF && c != '\n')
*cp++ = c;
if (c == EOF && cp == s)
return NULL;
*cp = 0;
return s;
}

But, honestly, why would you?

 

[CBFalconer]

.... snip ...

And how many YEARS will it take for those people to realize that
gets() is not really a good idea? It is already one year more or
less since they started this isn't it?

Boy, I surely do not get the "standardization process". I just
do not get it why it is SO difficult to just

(1) Select the text that defines the gets() function
(2) Press the "delete" key
(3) Save

Boy, I do not get it. I am too stupid for that. I need a
freshman class in the "standardization process".

Sane standardizers do NOT simply make existing conforming code
erroneous. Believe it or not, some users of GCC would like to
apply it to source code they have been using unchanged since Jeanne
d'Arc died, without having it abort on errors. So gets will NOT
just get deleted. It WILL get deprecated.

 

[jacob navia]

Finally, in the unlikely event that jacob ever decides to do something
more productive about these issues than complain in this newsgroup about
how stupid he thinks the committee is, what should that something be,
and what is the deadline for doing it in time for this version of the
standard?

Look Mr

(1) Nowhere I have insulted anyone, nor I am saying anywhere that some
people are stupid. You are putting words on my mouth.
(2) Yes, I disagree with some decisions of the committee. This never
means that I think that people are stupid because they do not agree
with me. Yes, I use irony, and yes, I have criticized the current
state of affairs. That is all.
(3) Concerning gets():
The only actions needed (since this function is ALREADY declared
obsolescent) is to delete the text that describes it from the
standard. This is very easy to do and needs no further
justification.
(4) Concerning asctime() I have proposed a drop in replacement for
the code presented in the standard in the discussion group
comp.std.c. The proposed code produces exactly the
same output for all inputs that are within range. I would like
to present this code in a formal way to the committee but I can't
afford to pay the plane tickets and hotel expenses for assiting to
the committee meetings somewhere in China or in San Francisco.

(5) To allow interested people to reach the committee I have proposed
that they have a web presence somewhere so that it is possible to
send them a document without having to pay 3000 US$ in plane and
hotel tickets. Not everybody has that travel expenses budget. I
pay all costs to keep lcc-win. I can't add to that the expense
of several trips per year to some place in the world.

 

[Phil Carmody]

Thompson wrote: [citing the working document]

The gets function is obsolescent, and is deprecated.

So, after all those discussions in comp.std.c, after all those
documents everywhere, after the thousands of pages explaining why
gets() is an error they STILL DO NOT ACKNOWLEDGE that gets() should
go.

Which bit of 'obsolescent' and 'deprecated' do you not understand?

Phil

 

[jacob navia]

Thompson wrote: [citing the working document]

The gets function is obsolescent, and is deprecated.

So, after all those discussions in comp.std.c, after all those
documents everywhere, after the thousands of pages explaining why
gets() is an error they STILL DO NOT ACKNOWLEDGE that gets() should
go.

Which bit of 'obsolescent' and 'deprecated' do you not understand?

Phil

This is since quite a while now. It is already in the current
standard.

What I can't understand is

(1) Why gets() is STILL in the standard text, since it is already
declared deprecated it could be DROPPED now!

(2) The only hint to its deprecation is in that footnote...

(3) If it gets (no pun intended into the standard it will remain
there until 2020. And no, I can't understand that.

 

[Walter Banks]

Look Mr

(1) Nowhere I have insulted anyone, nor I am saying anywhere that some
people are stupid. You are putting words on my mouth.
(2) Yes, I disagree with some decisions of the committee. This never
means that I think that people are stupid because they do not agree
with me. Yes, I use irony, and yes, I have criticized the current
state of affairs. That is all.
(3) Concerning gets():
The only actions needed (since this function is ALREADY declared
obsolescent) is to delete the text that describes it from the
standard. This is very easy to do and needs no further
justification.
(4) Concerning asctime() I have proposed a drop in replacement for
the code presented in the standard in the discussion group
comp.std.c. The proposed code produces exactly the
same output for all inputs that are within range. I would like
to present this code in a formal way to the committee but I can't
afford to pay the plane tickets and hotel expenses for assiting to
the committee meetings somewhere in China or in San Francisco.

(5) To allow interested people to reach the committee I have proposed
that they have a web presence somewhere so that it is possible to
send them a document without having to pay 3000 US$ in plane and
hotel tickets. Not everybody has that travel expenses budget. I
pay all costs to keep lcc-win. I can't add to that the expense
of several trips per year to some place in the world.

(1)(2) Your irony is not helping your cause.
(3)(4) Make your argument in a formal paper then present and argue your
position on the addition changes you want. Show your position
represents a reasoned position for the language.Be part of the
document trail that standards need to support the choices being
made.
(4) Actually the next meeting is in Canada. You have a vested interest
in the C language and without your presence your customers have
a limited voice in changes in WG14.
(5) There is plenty of web presence, committee documents are on line
many committee members are active on news groups. The formal
process requires sincere debate by interested parties to work.What
is on the newsgroups is editorial comment.

Regards,

 

[Guest]

(4)     Actually the next meeting is in Canada. You have a vested interest
          in the C language and without your presence your customers have
          a limited voice in changes in  WG14.

air fares to Canada do not grow on trees

(5)     There is plenty of web presence, committee documents are on line
          many committee members are active on news groups. The formal
          process requires sincere debate by interested parties to work.What
          is on the newsgroups is editorial comment.

maybe there a good reasons why things work the way they do. But the
process
*does* exclude people (maybe deliberatly) who can't afford the time/
money to
zip around the world