safe scanf( ) or gets

[Eric Boutin]

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or gets
function... I mean.. if I do :

char a[256];
scanf("%s", a);
and the user input a 257 char string..
that creates a problem.. same for gets..

even if you create a char array that's 99999999999999 char long.. if the
user input something longer it will still be a bug.. and I don't want
this..

<OT>
C++ have std::string that dynamicaly realloc themself if they are running
too big, but what about us ?
</OT>

I though about using character input function, from stdin, and then create a
string with this single character, then appending this character to the then
end of a string, and if the string gets too small, realloc( ) a bigger
one.. however this is quite annoying to do this each time I want to read
input.. yes I could create a function with this.. and that's what I gonna
do.. however I was wondering what you C experts were doing to avoid a
segfault or a bug in a such situation

thanks !

[nrk]

Eric Boutin wrote:

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or
gets
function... I mean.. if I do :

I don't know of any safe way to use gets. Use fgets instead where you can
specify the maximum number of characters to read into your buffer. With
scanf, the same can be achieved by specifying a maximum field width in the
conversion specifier (see below).
char a[256];
scanf("%s", a);
and the user input a 257 char string..
that creates a problem.. same for gets..

even if you create a char array that's 99999999999999 char long.. if the
user input something longer it will still be a bug.. and I don't want
this..

You can avoid this problem by specifying the maximum field width in the
conversion specifier:
scanf("%254s", a);
which will read a maximum of 254 characters into "a". Read the
documentation of scanf for more details.
<OT>
C++ have std::string that dynamicaly realloc themself if they are running
too big, but what about us ?
</OT>

You'll have to roll your own unfortunately.. . but... (see below)
I though about using character input function, from stdin, and then create
a string with this single character, then appending this character to the
then
end of a string, and if the string gets too small, realloc( ) a bigger
one.. however this is quite annoying to do this each time I want to read
input.. yes I could create a function with this.. and that's what I
gonna
do.. however I was wondering what you C experts were doing to avoid a
segfault or a bug in a such situation

Several regulars in this group (CBFalconer, Richard Heathfield, Morris
Dovey) have developed functions that do something along the lines of what
you want. Even if you want to roll your own, search the archives for a
thread with subject "Reading a line from a file" to get the URLs for the
same, to get a feel for how to go about it.

-nrk.

ps: This question seems to crop up so often around here that perhaps it
should be added to the FAQ?
thanks !

[Malcolm]

"Eric Boutin" <er**@nic.nac.w dyn.de> wrote in message

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or > gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.

There are plenty of functions knocking around that read an arbitrary-length
string from stdin. You only have to write these once.

The advice to replace gets() with a call to fgets() and throw away the
trailing '\n' is bad, since you replace undefined behaviour with wrong
behaviour on overflow. To use fgets() properly you have to take action on
overflow, which makes the program complex.

[Martin Dickopp]

"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:

The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a computer,
programs which read from standard input and write to standard output (AKA
filter programs) are absolutely mandatory, IMO.

Without filter programs, computers would be useless to me. (I would also
be unemployed, because my work would be impossible.)
if it needs a large number of inputs these are given in an ASCII file,
I don't understand. A text file can contain arbitrarily long lines, just
like standard input. How does reading from a file instead of standard
input change the situation?

(In fact, on many operating systems, standard input can be redirected
from a file, and a file name is provided for the terminal, so IMHO it
doesn't make much sense to distinguish between standard input and named
files.)
and if it really needs interactivity then it uses a GUI.

Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people (including
myself) prefer non-GUI programs to GUI programs.

Martin

[Malcolm]

"Martin Dickopp" <ex************ ****@zero-based.org> wrote in

"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:

The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a
computer, programs which read from standard input and write to
standard output (AKA filter programs) are absolutely mandatory,
IMO.

Sound like someone knows about a world which I know nothing about.

and if it really needs interactivity then it uses a GUI.

Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people
(including myself) prefer non-GUI programs to GUI programs.

Then we realise that we are more probably dealing with an eccentric. GUIs
have swept the board for interactive programs.
I don't know about filter programs - maybe in mainframe environments with
non-user generated stdin. As a games programmer I would never use nor write
a program written in such a fashion.

[Martin Ambuhl]

Malcolm wrote:

"Eric Boutin" <er**@nic.nac.w dyn.de> wrote in message

Hi ! I was wondering how to quickly and safely use a safe scanf( ) or >
gets function... I mean.. if I do :

The real answer is that stdin is seldom used in real programs. If the
program takes a few parameters from the user these are passed on the command
line, if it needs a large number of inputs these are given in an ASCII file,
and if it really needs interactivity then it uses a GUI.

This is grossly untrue. *Many* real programs are filters, taking stdin as
the default source.

There are plenty of functions knocking around that read an arbitrary-length
string from stdin. You only have to write these once.

The advice to replace gets() with a call to fgets() and throw away the
trailing '\n' is bad, since you replace undefined behaviour with wrong
behaviour on overflow. To use fgets() properly you have to take action on
overflow, which makes the program complex.

This is ridiculous. Only someone who doesn't know how to discard the '\n'
properly could have written such drivel. Of course it is not "bad" to call
fgets() and discard the trailing '\n'. What is necessary is to decide what
to do when there is no trailing '\n', and the level of complexity involved
need not be large at all.

--
Martin Ambuhl

[Irrwahn Grausewitz]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote:

"Martin Dickopp" <ex************ ****@zero-based.org> wrote:

"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:

The real answer is that stdin is seldom used in real programs.
I strongly disagree. In fact, to get any /real/ work done with a
computer, programs which read from standard input and write to
standard output (AKA filter programs) are absolutely mandatory,
IMO.

Sound like someone knows about a world which I know nothing about.

You don't know about operating systems providing command line
interfaces? Can't believe that.

and if it really needs interactivity then it uses a GUI.

Again, if this is supposed to be general advice (it sounds as if it is,
sorry if I misunderstood you), I strongly disagree. Many people
(including myself) prefer non-GUI programs to GUI programs.

Then we realise that we are more probably dealing with an eccentric.

Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.
GUIs
have swept the board for interactive programs.
stdin and interactive input are not equivalent. In a typical
environment input and output of a program are often redirected
to/from other sources. Remember: stdin/stdout/stderr are streams
which may be connected to a console, or a physical file. From C's
POV there's no difference, hence the rule: never use gets (for
suitable values of 'never').
I don't know about filter programs - maybe in mainframe environments with
non-user generated stdin.
A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...
As a games programmer I would never use nor write
a program written in such a fashion.

Not all the world is a Wintel box. ;-)

Regards
--
Irrwahn Grausewitz (ir*******@free net.de)
welcome to clc : http://www.angelfire.com/ms3/bchambl...me_to_clc.html
clc faq-list : http://www.eskimo.com/~scs/C-faq/top.html
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...acllc-c++.html

[Malcolm]

"Irrwahn Grausewitz" <ir*******@free net.de> wrote in message

Then we realise that we are more probably dealing with an eccentric.
Nobody preferring a console interface over a GUI is an eccentric,
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.
A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...
Well grep you would usually invoke with the name of the file to search.
"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI. I have never had any reason to
use the other utilities mentioned.
Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.

[Malcolm]

"Martin Ambuhl" <ma*****@earthl ink.net> wrote in message

This is ridiculous. Only someone who doesn't know how to discard
the '\n' properly could have written such drivel.
Well the FAQ showed to "replace gets() with a call to fgets()", and
discarded the trailing '\n', which means that undefined behaviour on
overflow is very likely to be replaced by incorrect behaviour on overflow.

If an experienced programmer like Steve Summitt can't get it right, then I
think we can say that fgets() is difficult to use.
Of course it is not "bad" to call fgets() and discard the trailing '\n'.
What is necessary is to decide what to do when there is no trailing '\n',
So how do you determine if there is no trailing '\n', if it's been
discarded?
and the level of complexity involved need not be large at all.

It depends what you mean. If you are comparing to some sort of analysis of
equations used in particle physics then, no, its not complicated. If you
mean that it adds substantial extra hassle to what should be a simple
process of getting a line from the user, then, yes, using fgets() properly
is complicated. You need to check the '\n', then discard the remainder of
the line, report an error message to the user (probably), and then loop to
get another line.

[Arthur J. O'Dwyer]

On Sun, 14 Dec 2003, Malcolm wrote:

"Irrwahn Grausewitz" <ir*******@free net.de> wrote in message

Nobody preferring a console interface over a GUI is an eccentric,
Careful about those generalizations , Irrwahn -- I bet I could
provide a few counter-examples if provoked. :)
but someone who knows about the power of command lines.

No its eccentric. Users generally won't accept command line programs unless
forced to use them. A GUI is generally far easier to use - I'm typing this
into a GUI newsreader.

Yes, and that's precisely one of the examples I was going to
bring up prevthread, as one of your apps requiring "more complicated
input" than your average non-GUI app can deliver. Also text editors
and programs computation- or I/O-heavy enough to really *require* a
progress indicator (e.g., my system's default invocation of 'wget').
Line-based text editors do exist, but IMHO only eccentrics really
*do* use those. ;-)
However, I frequently use a command-line compiler (gcc), which
is IMHO orders of magnitude more powerful and user-friendly than
the typical Visual offering. And of course if you've ever used
an MS-DOS Command Prompt on your Wintel box, you've seen how programs
like 'copy' and 'dir' can be useful from time to time. :)

A lot of standard command line utilities on a vast number of OSs are
filter programs. For example, you virtually can't do anything useful
on a typical *nix system without using stream filters, e.g. grep,
head, tail, sed, awk, gzip, more, cut, sort, ...

Well grep you would usually invoke with the name of the file to search.

Yes, but you may not have known that you can *also* invoke 'grep'
like this:

c:\> grep 'hello' < myfile.txt
or
c:\> dir /s | grep "myprog.exe " | sort

which last is a complex operation which to my knowledge cannot be
performed by any of the out-of-the-box GUI tools on Windows XP
(although third-party tools exist, of course). See, command-line
tools can be very useful for the everyday tasks of people who know
and use computers every day -- even if gamers don't need them.

Not all the world is a Wintel box. ;-)

Just the vast majority of general-purpose computers in use today. Even jobs
that used to require a mainframe can now often be done on PCs. Things like
supermarket checkouts and airport information screens are often PCs
underneath.
The vast majority of medium-sized systems that aren't PCs are probably games
consoles. They don't use command lines either. Nor do mobile phones.

BZZT. How do you think those phones are programmed? I'm willing
to bet, even though I don't know, that the guys who work for Nokia
or whatever have on their desks little gray boxes with cords that
plug into ports on the phones and interface with the phone's
file system at a rudimentary command line level. Because line-
driven shells are easy to write, and GUIs are hard (generally
speaking).
And a note in passing to look up "Linux" sometime -- it looks
like it might be becoming more popular in both the commercial and
home markets. :)

-Arthur