Re: gets(); was: Re: Why does rewind() ignore errors?

On Fri, 30 Jun 2006 12:07:56 UTC, kuyper@xxxxxxxxxx wrote:

Herbert Rosenau wrote:
...
When one has to read data from a file then gets is even exactly so
useful as any other input function standard C delivers.

gets() can only be used to read from standard input, whereas other
functions can read from files that aren't connected to standard input,
so "exactly as useful" would seem inaccurate on that count alone, even
if you ignore the fact that it provides no method for preventing buffer
overrun when unexpected input is provided.

You knows not what freopen is for.

Anyway whoever uses fgets, scanf and other standard C input functios
for emmittin user input gets a risk of reading something he would
never.

That's an icomplete sentence, so I'm not quite sure what you were tying
to say, but all of the other functions can be used in a way that allows
you to validate your inputs in order to prevent undefined behavior in
the event of unexpected inputs. gets() does not.

Using gets to read from a trustworth source is never wrong.

Correct. The mistake was made when you assumed the source was
trustworthy. There's no portable way to make standard input
trustworthy.

for (i = o; i < no_of_files; i++) {
fp = freopen(files[i].in, "r", stdin);
fp = freopen(files[i].out, "w", stdout);
if (fire_up_handler(files.i) {
die_on_error(files[i].err)
}
}

stdin is something it is set too, not only a tty, a screen or related.
There are really complex application systems using so primitiv
functions as possible.


Using scanf to read from a source you can't trust is errornous. The

Not if you use scanf() in ways that allow you to test the input for
validity, before using it in ways that might otherwise cause problems.

Ever programmed a big system havin about 300 little applications as
helpers available and a bit complex data structure to handle on?
Whereas the data is to handle as untrusted because it is NOT really
checked beause the person who has to create it knows nothing about the
content but can type nearly errorfree really quickly? Ever worked with
files created through a scanner with OCR and you have to verify all
that automatically?

only thing is buffer overflow - but at least I've ssen fgets(buffer,
4098, stdin) whereas the real buffer was only 25 bytes.

The difference is, fgets() can be used safely as well as unsafely -
you've just given an example of unsafe usage; gets() can only be used
unsafely.

It can be used easy safely when you can trust the source. it is a
mehtod to get quickly through data you knows nothing exactly as the
maximum size of each line as the data is written by a program that has
nothing to do than to read something, do some formal checks and write
its input in a known line length.

gets is definitely a fine function when you knows its limits.

In more than 25 years of programming user interfaces (commandline,
GUI) I've learned that C has not a single solution to get data in
secure except getc/fgetc and do all checks by hand.

There's lots of incorrect ways to use the other input functions, but
used correctly, they can be just as safe, and much simpler, than using
that approach. gets() is the only one that can't be used correctly in
code that's intended to be portable.

That is really untrue.

Computers are crated to handle mass input, generate some output as
input for other programs.

Whenever a trusted source of the data stream was used gets is nice and
handy - except there is more to read as a simple text.

stdin can't portably be considered a trusted source.

Not true. Yoiu can write big packages in strictly conforming C. Not
each program needs user input but reads from stdin and writes to
stdout and stderr. In 20 years it will never touched by a human but
called by other programs. stdin does not mean that there is a keyboard
There can be a simple stream whoes source is somewhere on the world
but known as secure. Read what you can do with streams connected to
pipes, queues and so on.

Would you ban any knife from the diner? It can easy be misused to kill
peoples. So one should ban them. The same is with gets. Use it right
and it works well.

Well, yes, with one key proviso: "use it right" means "use it never".
Knives can be used safely, gets() can't be.

You should forget your prejudice against gets. There are lots of
really save applications around who use gets because it makes no sense
to check the stream some 1000 times again and again because the
creator of the stream is well known as secure.

Have you ever written a strictly conforming application designed only
to fill input streams of other applications?

Programming starts with design. Design will fall into more complex
design until you get the whole system designed.

Simple design rules:
- make anything so simple as possible.
That means if you have a complex problem break it down to a
number of smaller problems. Iterate until the problems are
really simple.
- don't trust a user
- separate user interface from work to do so good as possible
- write so much code as ever possible portable
- separate strictly anything that can not written portable from
anything that can been written portable.

I've written lots of applications using simply gets because it was the
most possible solution for that problem. These programs were never
connected to a keyboard or an unsecure human interface.

I've written even more programs using simply getc() because it was a
better solution for the specific jobs.

I've avoided gets in lots of applications based on its design flaws.

To find the right function you has simple to know its limits. Whenever
I have to write a user interface I avoid scanf because error checking
(user typing) is too complex to get it both right and simple. In such
situation gets is so far from a possible solution I would never think
on it.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!
.

Relevant Pages

  • Re: Windows temp folder?
    ... > design, not by OS design, and you can't really consider it a standard. ... folders which contain thoose so I figured the same applies to WM, ... there are some applications that 'clean' PPC device ...
    (microsoft.public.pocketpc.developer)
  • Re: question about component integration or assembly
    ... File Design and File Indexing ... Microcomputer Applications by Graurer and Sugrue p. 370, ... management system also provides the ability to delete records as well as add ... Programmers and database users also find SQL to be valuable ...
    (comp.object)
  • Re: Target market for Intellasys.
    ... I would like to see a full speed general purpose embedded serial interconnect IO bus standard. ... Looking through serial memory I found something like a maximum of 70mhz speed which is pretty useless if it was the only bus in a cutting edge design. ... All other control mode levels also have this ability, to allow developer to instigate their own versions of the features not defined in that level, as they wish, if they wish. ...
    (comp.lang.forth)
  • Re: My First C# (warning - long post)
    ... In several IBM mainframe shops (which is what I knew best in those ... move to many classes with small method applications. ... The one main OO design point that you should eventually spot from ... and all hold onto the **Single Responsibility Principle. ...
    (comp.lang.cobol)
  • Re: Interface standards (was Re: Dual Port RAM)
    ... I find there lack of a standard on the 'internal' side to be ... principle of abstraction; instead of hiding complex functions behind ... simple interfaces, ... write the code for because it is just a sub-function of the overall design. ...
    (comp.arch.fpga)
Loading