Richard Heathfield said:
Al Balmer said:
Incidentally, I am unable to find this article[*] with a Google Groups
search of comp.std.c. Does anyone have a link?
Message-ID: <
[email protected]>
[* An article by Doug Gwyn in comp.std.c, saying that gets() will be
deprecated in the next Standard.]
Indeed, I can't find this via Google. But my local news server
has it. See below:
----------------------------------------------------------------------
From: "Douglas A. Gwyn" <
[email protected]>
Subject: Re: security enhacement to C runtime library (XXX_s)
Newsgroups: comp.std.c
Date: Tue, 24 Apr 2007 21:47:36 GMT
Organization: U.S. Army Research Laboratory
Now explain to me what can you really in a practical sense do about
this. If C had exception handling, then you could make a case, but it
doesn't so? You're going to call exit(-1) instead? I hope you saved
all your open documents in the program.
Because the behavior is controlled, you can safely save the state
of the work files, etc. Indeed, you can even simulate throwing an
exception by invoking jongjmp to regain control at a convenient
point in the overall algorithm. There are several implementations
of nested exception handling packages in Standard C.
With undefined behavior, you typically get a random crash leaving
data in a corrupted state, or worse yet get exploited by a "hacker"
who uses the overrun for nefarious purposes under *his* control.
Thus creating a new code synchronization issue. Congratulations. You
don't have any mathematicians (people who understand what a
mathematical closure is I mean) or people who have used Ruby, or
Python on the committee do you?
Sure we do. I know it's hard to believe that smart people could
come to any conclusion different from the one you come up with,
but it happens. Often it is because they are balancing a different
set of trade-offs or at least assigning different weights to them.
I had major problems that prevented me from considering contributing
to the ANSI standard:
If you don't participate, how do you expect to impact the outcome?
1) You are not open to the idea of *TAKING THINGS OUT* of the standard
library.
Unless there is really strong justification, altering the behavior
of features which have been relied upon as guaranteed to be supported
on every conforming implementation (including dropping the guarantee
of their existence) does a disservice to the huge amount of existing
code that relies on the guarantees. Therefore, there is *rightly* a
strong predisposition on the part of the standards body to maintain
existing interfaces. However, ...
2) You have overtly distorted reality in your C rationale in the past
to cover up for the embarrassment that is gets().
.... actually, gets has been declared an obsolescent feature and
deprecated, as a direct result of my submitting a DR about it
(which originally suggested a less drastic change). (The official
impact awaits wrapping up the latest batch of TCs into a formal
amending document, and getting it approved and published.)
3) If I were to propose Bstrlib for inclusion into the standard, and
it were to be accepted, it would *WORSEN* Bstrlib, because it would be
included by some/most compiler vendors in a closed-source manner. One
of Bstrlib's capabilities relies on the fact that it is open source
(replaceable allocation functions), and the security statement is
meaningless unless the source is available. So I declined the
potential wide-spread notoriety and usage I might have gotten for
Bstrlib if it were accepted (but lets be honest, you guys would not
have given it a fair shake anyways) in exchange for retaining its
status for maximal capability.
When submitted appropriately within the process, proposals are taken
quite seriously and are given fair consideration. A lot of what has
been standardized started out as such proposals. Of course, they had
active participants promoting, explaining, and shepherding them.
4) When I have made suggestions of proposals in the past I have been
met with nothing but derision from you people. There was also an
excellent and really necessary time generalization proposal (I don't
remember who made it, but it was from a regular here; Dave Tribble
maybe?). I don't see that proposal in the current TR. Its obvious
you people just don't care about important capability issues.
I doubt that anything you submitted for consideration by WG14 has
"met with derision". There was in fact an extended time function
proposal that spun off from an earlier proposal which had been found
to have problems too late in the C99 revision process to make it into
the last version of the standard. Tribble has indeed been working to
refine and improve that, although so far as I recall it has not been
proposed as a Work Item, which would be necessary for the committee
to being working on a TR in that regard. Of course it is unrelated
to the buffer-limits TR.
