>>1
It's kept on the standard because some old code relies on the existence of gets(). (Note that SUSv4 deprecates gets(), but C99 does not.)
This is what C is about: putting the standard more on the service of bad-written junk of the 60's than on the service of current needs and current technology. There is nothing really intelligent about C -- not nowadays, not even about ten years ago, when the standard was on its conception. Many decisions inside C are pathetic at the very least. C lacks the notion of keyboards or monitors; but the standard library has support for internationalization and formatted output of monetary quantities. Fuck, for what reason, if possibly no screen exists for output, no device exists for input, and there is no portable way of knowing if 'A' translates to 0x41 or to 0xLOL because the execution charset is let unspecified? C not only lacks the concept of threads, but the execution model itself does not support it at all: POSIX and C are actually the description of two _completely different_ languages, since they differ in a core aspect. C does not know what networks are, let alone network protocols; C is ignorant about filesystems, let alone databases or query mechanisms. C lacks screens, how come it could ever be able to standardize _any kind_ of GUIs? C really can calculate a lot of things, but you shouldn't expect too much about actually _seeing_ what these things are, or, better stated, you shouldn't expect too much about how to _input data_ through a myriad of pathetic scanf() format strings, since such is the best approach of C for 'data formats'. C has no well-defined binary format -- not in the standard, at least. C has no notion of libraries. C has no notion of fixed-point calculus (but knows every possible useless aspect of floating-point exceptions, albeit _no_ current compiler implements every one of them). And C still haven't decided whether executing '-x', being 'x' a signed integer, is undefined behavior or not, because C haven't decided much about integer representation, bitwise operation on signed words and overflow conditions. C is a victim of 'trap representations' as much as about a single piece of assembly-language code is victim to spurious interrupts in the hardware level.
Note that neither of these concepts -- networking, filesystems, threads, word-sizes -- are extraneous nowadays, nor completely impossible to standardize, due to the amount of common practice that yields _de facto_ standards of their own sort. SUS defines a set of functionalities as optional; why standard C doesn't have a couple of its own?
The reason is that, for C, there is no real evolution -- just a repetition of old, out-dated arcane kludges, marketed sometimes as 'serious programming' to preserve the renown of an elitist subset that actually outperforms their peers in regards of knowing every possible undefined behavior condition. Actually, such behavior is the hallmark of C: for anyone familiar with C programming communication channels, on IRC, Usenet or other such cesspools, knows heavily, and by the harsh way, that the common behavior of the C community is to act according to some sort of Sabbath code of conduct, praising FUD as a real deity, bashing heavily over newcomers with the 'READ THE STANDARD' crowbar, and over legitimate, complex doubts with the 'THIS IS OUTSIDE THE STANDARD'S SCOPE' excuse. In C communities, ignorance is regarded as a strong weapon to keep the status quo untouched. The things go even worse inside C++ communities, albeit C++ is such an abomination that it is comprehensible why adepts of it behave likewise.
C is the hallmark of blatant barbarism and techonological stagnation. C is obsolete, and was obsolete a decade ago. The fact that 70% of the world software is still developed in C, or running a C compilation, is no argument to counterfeit the fact that C is not capable, and has never been, of dealing with anything better than manipulation of simple byte strings; and even then, the result is _guaranteed_ to be unportable at the very beginning. There are _no_ non-trivial C programs completely free of undefined behavior conditions, because such thing is almost infeasible in theory, and in practice no one really gives a fuck ('If it crashes, just restart it'). Portability is a joke on technology, but it is really taken to an extreme dimension, in C: ill-defined word-sizes, unspecified endianness, unspecified character sets, unspecified memory models, unspecified file formats, unspecified pathname formats, and so on, _ad nauseam_. C compilations have the incredibly retarded bottleneck of simple file I/O due to the extensive copy-pasting (a reality in the old era, a dementia in the new world) of standard header files in _every single translation unit_; and typical C projects extensively lack organization, even in the directory-hierarchy level. C front-ends are completely incompatible (there's barely a portable way to simply compile a translation unit, without any extensions or compiler flags, and even expect the result to be usable between compilers without a bunch of quirks to select call models, symbol naming and so), which propagates to the impossibility of creating portable makefiles, which propagates to the need of developing GIGANTIC balls of shit such as Autotools, Libtool and other GNU smelly crap. C is the cause of tremendous amounts of scripting kludges, severe security bugs and man-years of wasted refactoring and rewriting of unintelligible code.
That said, C is indeed a misdesigned, underspecified and braindamaged language; actually, a 40-year old prank that got incredibly far in computer history much more because of political influence than because of technological quality, if there are any. Not that there are _really better_ alternatives to circumvent the problem with -- maybe this is the reason why C is still widely in use. C is to programming as Unix is to operating-systems, and as lobotomy or trepanation is to headache treatment. People use Unix because there's no better alternative, as general things goes, not because Unix is a good OS in any regard. People use C for the same reason. People drugs themselves not because drugs are good for your health, but because life sucks _even worse_ without them.
In the current technological portfolio, adoption of any one of the available 'choices' are a _consequence_ of the absence of a marginally decent alternative.