Marcus said:
We all know that the "gets" function from the Standard C Library (which
is part of the Standard C++ Library) is dangerous. It provides no
bounds check, so it's easy to overwrite memory when using it, and
impossible to guarantee that it won't happen.
There is an infinite variety of things you can write in a C++ program
which will render it undefined and potentially dangerous in some
situation. Calling the gets() function is just one of these things.
Among harmful things, gets() is one of the easiest to diagnose. It's
easy for an implementation to detect that a program calls gets(), and
issue a diagnostic. Quite simply, the program's translation units
contain an unresolved reference to that function.
Therefore, i think it's surprising that this function has not been
deprecated.
Deprecated is only a status change that exists in the minds of the
members of the community. It has no practical impact on what's
happening in the actual software.
A C or C++ implementation is free to emit whatever diagnostics it
wants, and to support stricter modes of operation in which it reject
some programs which are correct according to the standard.
For instance, if you run the GNU C compiler with '-Werror', it will
reject all programs for which it emits any kind of diagnostic. Even
something harmless like the suggestion of extra parentheses, or the
definition of a variable that is not used.
I know of one environment provides a warning when a reference to gets
occurs among the translation units of a program being linked to produce
an image.
There are also environments that support bounds checking on objects,
such as compilers that use a '"fat" representation for pointers, and C
interpreters. The gets() function is harmless, to the extent that if it
overruns the array, the condition will be detected and turned into a
diagnostic. I.e. there are conceivable situations in which gets() isn't
disastrous.
So it's basically up to implementors and their community: what they
care about.
Now, the C standard committee is working on safe functions (the ones
that end with "_s") for the C Standard Library. I don't know if they
are going to deprecate the dreaded "gets".
gets is not "dreaded". Only dumb programmers are "dreaded". Dumb
programmers will foil any attempt to provide a safe environment. The
only way to make the world nearly 100% safe from dumb programmers is to
put them on an island with no Internet connection.
If you "dread" gets, you have some emotional problem. Normal people
don't think about it, let alone regard it as some Bogey Man.
getting rid of "gets" is not that hard, isn't it?
Yes, don't use it!
Programs that use it are broken anyway.
Not necessarily. Suppose I have a compiler application which is
separated into two programs, the compiler proper and an assembler.
The compiler generates assembly code, which the assembler reads from
its standard input.
My compiler never generates lines longer than 1023 characters, by
design. So the assembler can safely use gets() on a 1024 character
buffer to read the compiler's output.
The assembler is part of my compiler application; it's not meant to be
used alone. So the interface between the two is a private interface.
Years ago I did some Motorola 68000 programming using the GNU assembler
that served as the back-end for gcc. With that assembler, if I
mis-spelled the mnemonic name of an instruction opcode, there wasn't
any nice error message with a line number. Guess what, the assembler
crashed with a segfault! That wasn't a problem, because the assembler
didn't have to be designed to handle incorrect input. It was an
internal interface to be used by the compiler, which put out correct
opcodes. I got my assembly routines working anyway and life went on.
If you think that's a bad idea to have such an interface, well consider
that modules in C and C++ programs often have such "unsafe" internal
interfaces between them. It's not unusual for pointers to arrays to be
passed around without any size being mentioned anywhere, because all of
the modules just "know" the size. It is some manifest constant that
comes from a header file.
If you linked that compiler and assembler into one program, the gets()
would disappear. The compiler would just pass char * pointers directly
into the assembler, which would be understood to point to arrays of
1024 characters.
How are you going to mark /that/ type of practice as deprecated?