Where do I get the latest version of the new standard?
jacob navia
exciting news.
Contrary to previous issues there was no announcement in this group.
Is it available somewhere in the net?
Thanks
Keith Thompson
The latest pre-201X draft is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1401.pdf>.
It has the changes to the description of asctime() (which merely
describe and expand the conditions in which its behavior is
undefined), but it still has gets(). Presumably the removal of gets()
will be reflected in the next version.
The C standard committee's web page is
<http://www.open-std.org/JTC1/SC22/WG14/>. It has links to various
documents, the latest of which are included in the "Pre Santa Cruz
2009 mailing available". You can also browse the
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/> directory.
Larry Jones recently mentioned in comp.lang.c that the next draft will
be N1425, which should be out in a week or two.
--
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"
Kaz Kylheku
> I have heard that asctime is fixed, that gets() is gone and other very
> exciting news.
I don't understand why those people don't make some bold moves and cut crap
from the language.
gets could /easily/ have been axed in 1989.
Old-style declarations, ditto.
See, just because you cut something from the language doesn't mean
that compilers have to stop supporting it.
Compilers have all kinds of extensions. Many compilers work in nonconforming
modes by default and have to be explicitly told to be conforming.
(And you know, those compilers have users which don't even know about
this, yet somehow ship code).
If it's okay for GNU C, for instance, to give us ``strfry'' when we
include <string.h>, the ``gets'' function, and other crap, can be
supported in a similar way: if it's important to the users of a particular
implementation to have gets, old-style declarations and other cruft,
then they can negotiate that support with their compiler vendor.
Other obsolete or historic features have been handled taht way
by compilers. For instance gcc used to have (don't know if it still
does) -fpcc-struct-return for returning structs in a static buffer.
Or there may be a way to allow null pointers to be dereferenced.
Or static literals to be modifiable. Legacy code depending on
legacy dialect features can be supported outside of ISO.
Dropping cruft from the language doesn't mean that suddenly the users of that
cruft are left without a way to compile their broken code.
Obsolescence phases are complete nonsense too. It's up to implementations to
manage obsolescence. I.e. ``this feature has been axed from the ISO language,
but continues to be supported in our compiler for a few releases''.
Problem is people with dicks don't like to sit in meetings.
Eric Sosman
> On 2009-11-25, jacob navia <ja...@nospam.org> wrote:
>> I have heard that asctime is fixed, that gets() is gone and other very
>> exciting news.
>
> I don't understand why those people don't make some bold moves and cut crap
> from the language.
>
> gets could /easily/ have been axed in 1989.
Perhaps.
> Old-style declarations, ditto.
A Standard that rendered *all* existing code invalid would
have found its rightful place on the bottoms of parrot cages.
> See, just because you cut something from the language doesn't mean
> that compilers have to stop supporting it.
No, but they'd have to issue diagnostic messages. A few
thousand "noise" diagnostics would have a pretty good chance of
drowning out a few "real" issues.
> Compilers have all kinds of extensions. Many compilers work in nonconforming
> modes by default and have to be explicitly told to be conforming.
> (And you know, those compilers have users which don't even know about
> this, yet somehow ship code).
In short, your recommendation is for a Standard that would
describe a compiler that never operated in the mode described.
What use would that have been?
> Dropping cruft from the language doesn't mean that suddenly the users of that
> cruft are left without a way to compile their broken code.
It means that if they want to compile their quote "broken"
endquote code, they must use a compiler that does not adhere to
the Standard. What other requirements of the Standard may they
ignore? Can they use sign-preserving integer promotions? Can
their sprintf() return a char*?
The value of the Standard lies not in its words, but in the
agreement by many implementations to conform to it. That's what
makes C code (potentially) portable: Not the Standard, but the
widespread support for the Standard. And if you begin with a
Standard that *must* be disregarded, portability is a goner.
> Problem is people with dicks don't like to sit in meetings.
... while people who *are* dicks like to sit and snipe.
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
> It has the changes to the description of asctime() (which merely
> describe and expand the conditions in which its behavior is
> undefined)
Well, it is all is needed:
<quote>
If any of the fields of the broken-down time contain values that are outside their normal
ranges, the behavior of asctime function is undefined. Likewise, if the calculated
year exceeds four digits or is less than the year 1000, the behavior is undefined.
<end quote>
This means that the standard doesn't have a buffer overflow error anymore, and from
my personal viewpoint this is a great progress!
In all my discussions here and in comp.lang.c about this problem, my goal was to get
rid of that buffer overflow. I thank the members of the committee for fixing that
problem.