safe scanf( ) or gets

[Les Cargill]

stdin in is commonly used in beginner programs. It is old-fashioned and is
seldom used in most areas of computing. Interaction with computers is via a
GUI, and lengthy input is by files, and generally it does not make sense to
pipe these to standard input.
You may be working with a legacy system where modern practises haven't
arrived, but don't pretend that this is common.

I have been using Unix/DOS pipes for 20+ years. I've
never had a Unix pipe stack dump, once, except
when an element of the pipe was under development.

It was no more a struggle to accept responsibility for
constraining line length to a resonable value than any
other responsibility, since the contents of all files
being "piped" were under control of the people on the
projects involved.

GUI tools, on the other hand, stack dump on a regular basis.
At more that one installation *it became standard practice
to reboot one particular server periodically to "cure" a
well-documented and well-known memory leak* in the blasted
thing. This for a very expensive software package. This
state of the art prevailed for *over one year*, and still
prevails, so far as I know. This is also a very mission
critical package.

Since the leading offender in terms of viral infection by
memory ovwerwrite is by declaration a GUI-only solution
( Windows ), I find the irony of this statement most amusing.

And the *kewlest*, Most eXtreme form of GUIism, the actively
server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily. The higher level
the tool (measure din Monster postings per package) used
to generate the website, the more frequent the crash.

Viva los CLI! GUIs are for people who can't operate text
editors! Add a CLI to a product lacking one, and you
will receive the most extreme gratitude of those who use
the thing See also "Cisco Corporation". At least they'll
be able to configure boxes while the GUI people are
consuming JOlt and pizza, mounrfully pulling all nighters
because the toolset is broken.

A good GUI is a joy to behold. There are , unfortunately,
almost no examples of a good GUI. The VC IDE is almost
the worst I have ever seen - without the help system, it'd
be unnavigable.

 

[Eric]

Pardon me, but b*llsh*t. I have an office full of users who require
fulltime assistance just to log their computers on in the morning. And
all of these guys have degrees.
GUIs are notoriously difficult to master. Few people get beyond the
basics, and still do most of their actual work by typing stuff in.

I am sure that if you wanted to look into it, you would discover the
research studies which show that a well-designed GUI is easier.

Unfortunately, it is quite easy to implement a poor GUI. Designing a
good GUI is not easy and takes far more thought and effort then many
have been willing to put into some of them.

 

[Dave Vandervies]

server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily.

Counterexample:
--------
dave@goofy:~ (1) $ telnet www.google.com 80
Trying 216.239.41.99...
Connected to www.google.com.
Escape character is '^]'.
get /search?q=small+http+client http/1.0

HTTP/1.0 200 OK
Cache-control: private
Content-Type: text/html
Set-Cookie: PREF=ID=33d2dac260e57c2e:TM=1071446738:LM=1071446738:S=IBljKP6SXXt9Z0tq; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Server: GWS/2.1
Date: Mon, 15 Dec 2003 00:05:38 GMT
Connection: Close

[snip page text]
--------
telnet is also a nice, easy, stable POP/SMTP client (and, I'm sure,
would also be a nice, easy, stable NNTP client if I could be bothered
to learn the protocol). Not necessarily something I'd want to use all
the time, but I've never known it to leak memory or crash.

Viva los CLI! GUIs are for people who can't operate text
editors! Add a CLI to a product lacking one, and you
will receive the most extreme gratitude of those who use
the thing See also "Cisco Corporation". At least they'll
be able to configure boxes while the GUI people are
consuming JOlt and pizza, mounrfully pulling all nighters
because the toolset is broken.

A good GUI is a joy to behold. There are , unfortunately,
almost no examples of a good GUI.

Seconded.
There are a lot of ways to get GUIs right (and, sadly, infinitely more
to get them wrong), but all the ways I've ever seen to get them right
have two characteristics in common:
-There is a way to type in commands to do things that the GUI Just
Can't Do, because there isn't room for all the pointy-clicky stuff it
would require to do it;
-The average user never needs to be aware of the existence of such
an escape hatch, and even the most advanced user seldom needs to use
it, because the GUI is not only sufficient but also effective for all
but the most arcane tasks that may need to be done.


dave

 

[Irrwahn Grausewitz]

Careful about those generalizations, Irrwahn -- I bet I could
provide a few counter-examples if provoked.

Well, so could I. What I wanted to write is: Nobody is eccentric,
just because he prefers console interfaces...

<snip>

Regards

 

[Irrwahn Grausewitz]

"Irrwahn Grausewitz" <[email protected]> wrote in message
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.

So do I, as you can see from the headers. But when this message pops
up on your side, it has passed several systems, most of which are most
likely administered via command line interfaces. So the maintainers
of the internet infrastructure are eccentric because of this? BS.

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.

Who is eccentric now?

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.

What have mainframes to do with this?

The vast majority of medium-sized systems that aren't PCs are probably games
consoles.

Not where I live. There's more than mainframes, PCs and game
consoles, you know...

And if you are really into game development you most certainly
encountered some kind of debugging interface built into the game
engine, which is nothing else but... yes, a command line interface.

They don't use command lines either. Nor do mobile phones.

The last time I checked my cell phone didn't have a GUI.

Regards

 

[Irrwahn Grausewitz]

Defined wrong behaviour can be worse than undefined behaviour. The goal is
not just to prevent the computer from crashing, but to prevent any sort of
undesired behaviour. A crash is actually the least dangerous malfunction -
no diferrent to the computer blowing a fuse.

What is really dangerous is people making such claims. And yet it is
so dead easy to achieve well defined behaviour *and* get the desired
results...

What is really dangerous is
wrong but reasonable-looking results.

And that is exactely what you will get (according to Murphy's Law)
when you write code that invokes undefined behaviour, for example by
using gets. Nothing forces the program to crash on buffer overrun,
virtually anything can happen, from seemingly correct operation to
Nasal Demons taking over the world.

Regards

 

[Les Cargill]

server-generated website, will *invariably* crash, for no
good reason, at random intervals. All HTTP clients leak
memory like a seive and crash merrily.

Counterexample:
--------
dave@goofy:~ (1) $ telnet www.google.com 80
Trying 216.239.41.99...
Connected to www.google.com.
Escape character is '^]'.
get /search?q=small+http+client http/1.0

HTTP/1.0 200 OK
Cache-control: private
Content-Type: text/html
Set-Cookie: PREF=ID=33d2dac260e57c2e:TM=1071446738:LM=1071446738:S=IBljKP6SXXt9Z0tq; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Server: GWS/2.1
Date: Mon, 15 Dec 2003 00:05:38 GMT
Connection: Close

[snip page text]
--------
telnet is also a nice, easy, stable POP/SMTP client (and, I'm sure,
would also be a nice, easy, stable NNTP client if I could be bothered
to learn the protocol). Not necessarily something I'd want to use all
the time, but I've never known it to leak memory or crash.

I wouldn't have originally considered
Telnet to be an HTTP client. I was really more thinking "web
browser". And some of the simpler web browsers may actually
not be leaky, but I dunno.

 

[Guest]

| Then we realise that we are more probably dealing with an eccentric. GUIs
| have swept the board for interactive programs.

It seems you are blind to reality. Sure there are plenty of GUI programs
and more coming along. But there are plenty of non-GUI programs around.
If every non-GUI program were to suddenly disappear, everything ... and I
do mean everything ... in the world would come to a screeching halt (much
of it because all the electric grids will be down).


| 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.

Your breadth of exposure to the field of computers is very narrow indeed.
Sure games are big, and there's money in games. But the real world is no
game. You better hope the game markets keeps going as I feel you could
not make it in any other field.

 

[Guest]

|> >
|> > 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.

You might call me eccentric, but GUIs really do slow me down. They are
most certainly NOT more powerful. CLI is the power. The catch is, CLI
requires extra effort to learn because it doesn't have much of a crutch
to lean on like some GUIs do. But it's obviously something you would
not be able to learn.


| 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.

You are living in a virtual game world apart from reality.

 

[Mac]

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.

Actually system administrators hate GUI's because they (sysadmins)
sometimes have to do the same thing over and over to many computers, and
what they really want is a way to script the action, while still allowing
a certain number of intelligent variables.

This is why Microsoft is now working on the shell to beat all shells.
(We'll se if they succeed, but they have recognized the deficit and are
trying to fix it.)

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.

Well, you should have enough humility and wisdom to realize that you are
only one person, and your experiences do not represent the full spectrum
of what's out there.

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.

You seem to be ignoring all the embedded systems. We seem to be moving
towards a world where every single product which consumes power has a
microprocessor in it. Those processors are mostly not running microsoft
software or GUI's, properly speaking.

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.

Yeah, but they are not wintel boxes, either, which is the claim you seem
to be trying to contradict.

Anyway, don't forget about routers and access points and so on. Behind the
scenes, they absolutely use command lines.

And don't forget about all the embedded systems that don't really have a
user interface at all. Processors in cars, for example.

Besides, a lot of people like command lines. I'm one of them. ;-)

Mac

 

[Richard Heathfield]

It is easy to write a bad GUI. Visual C is fine most of the time, but
occasionally won't let you into the system. For instance, I once made the
mistake of allowing it to create a "shell" project for me. It created a
header called "stdafx.h", then when I added a pre-existing source file,
started complaining about precompiled headers not being found an all sorts
of nuisance. After about a hour messing about with it I finally gave up,
deleted, and started over by hand.

Yes, these things should be turned off by default, IMHO.

For functions designed to save time,
such as pre-compiled headers and wizards, actually became time wasters.
This is quite common.

Right so far. Great! I am in complete agreement with you!

Using a non-GUI compiler, for a simple program it is of course easier to
type "cc foo.c" and everything will work.

Still in full agreement. Surely this can't last?

For a complex program you would
use make and a makefile (not stdin). make files aren't the easiest things
to write and maintain, though at least you are in control.

And of course you have full access to stdin within the programs invoked by
make, should you need it.

And that's the sort of reason why users won't accept command lines.

Actually, it's a good reason why they might. But we aren't even beginning to
scratch the surface of the CLI's power. Here's a very slightly more
powerful example. In my dev directory, I have 72 subdirectories at present.

How do I know? ls -al | grep ^d | wc -l - that's how!

Okay, so where in that lot do I use my routines to connect to, or disconnect
from, an SMTP server? Ah...

find dev -name \*.c | xargs grep SMTP[CD]

Using Windows "find" we can look for files or folders named "myprog.exe",
and the GUI leads us through it.

Yes, and it's *slow*. What's more, it's harder to use than a CLI (IMHO,
having tried both).

We can then double-click on the icons it
brings up to see what's in them.

Doesn't sound very scriptable to me.

However you do lose some flexibility -
you can't pipe to your own version of "sort" which handles numerical
values as numbers (so x2 is before x11), for instance.

That's not the only flexibility you lose.

It's only likely to succeed if it can protect the user from needing to use
the command shell.

On the contrary, it has already succeeded. Incidentally, just like Windows,
it gives the user the *choice* of a powerful[1] command shell, or a weak
but pretty GUI.

[1] The default Windows command shell is nowhere near as powerful as Linux's
various shells, IMHO, but hey, you can always use Cygwin.

I can't use it since I need to run programs that only
work on Windows.

Why not do the world a favour and port them to Linux?

 

[Richard Heathfield]

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.

The advice is correct (so far as it goes).

So how do you determine if there is no trailing '\n', if it's been
discarded?

Because /you/ are the one who does the discarding, and you *remember* (or
rather, your code does).

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.

It's trivial to wrap this up into a function that dynamically resizes a
buffer; in fact, several of us here have done so (and published our code).

 

[Christopher Benson-Manica]

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.

If by "users" you mean the mass of people who use their computers to
surf the web, then sure. Many people who require more from their
machines than web surfing, however, find command line and text-based
utilities to be far more useful. I am typing this post in a
text-based newsreader (tin) running on a FreeBSD box in Texas while I
sit comfortably in an office in a suburb near Atlanta. I use the mutt
mail reader for my mail, and it is both much faster and much easier to
use than Outlook. Even the GUI utilities that I'm forced to use as a
part of my job (Borland's C++ compiler and make utility and Microsoft
Visual SourceSafe) I find to be much more effective when run from a
DOS prompt. I don't feel that I'm alone in these preferences with
respect to the professional computing community.

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.

Since when is more quirky? more myfile.txt - what could be simpler?
I suspect that you are missing out in a big way by disregarding
command line utilities, unless of course you *do* treat your computer
as a toy.

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.

I agree insofar as the majority of computer users are not involved in
the programming and maintenance of the systems in question. Those who
are, as well as a number of flat-out enthusiasts, typically fall
squarely on the side of command-line utilities.

 

[The Real OS/2 Guy]

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.

We've seen you knows nothing about real computeing. Even as I type
this message in a GUI newsreader here are about 3 douzend console
programs active - whereas one of them does nothing but watching and
steering a GUI program for unattended process. Without active
stdin/stdout/stderr it would unable to do its work. This GUI program
runs 24h/7d unattended. It has its GUI only for the seldom case I like
to do some action manually or have a quick look at the logs. But the
latter would even so easy by a commandline program like less.

No, I don't use M$ software because M$ has proven itself to be
incompatible to anything - even to itself even in standard C.

My OS has the best possible GUI, yes - but even that is not enough for
lots of actions I have to do dayly. Nothing gives more flexibility in
work than a commandline interface - even as something gets done more
comfortable with the GUI.

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

No, not always.

"more" does use redirection, and it is a quirky thing to use - basically a
patch on the other utilities not being GUI.

Absolutely wrong. You don't know how to combine streams to get theyr
full power.

I have never had any reason to
use the other utilities mentioned.

Hm, as a person who knows nothing as using a GUI to click around to
combine predefined codesecuences to a new game you knows at least not
even how to program really. As a real programmer you would not even
use a GUI (even as you may use a GUI oriented editor) to build
programs instead clicking around. You should know how to use make, how
to pipe the compiler listing into your editors command window to steer
it to help you to fix your self programmed bugs.

Just the vast majority of general-purpose computers in use today.

is unable to run windows. It has not even another kind of GUI. The
advertizing of M$ is nothing than marketing for dumb users. Windows
GUI gets quickly unuseable when it comes to real facts and not only to
click, click.

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.

Right, but that is nowhere the mayority of computers. You've seen the
computers inside your car, your TV, your DVD player, your switch, your
router, your hard disk, your, monitor, your keyboard, your printer,
your camera, phones? There are more computers in your househeld, your
car, your car radio, trains, aircrafts, ships, motor cycles, boats,
mashines, .... as you would dream off.
Computer are conquering dayly more new fields you would never think.

There are computers with more power on a single board that 10 PCs who
have a comfortable user interfaces - but no keyboard and no screen, no
printer, no mouse, no GUI. PCs are only an absolute minority of the
wide fields where computeres running. GUIs are used soldom - but
commandline oriented user interfaces sofrequent as sand on the sea.

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.

But there more computers in only mobile telephones than game consoles.
There are more computers in factories, stores, mashines and so on than
PCs. Not each PC uses a GUI, many modern PC have never seen an monitor
attached, many PCs have never seen an hard disk attached, so many PCs
are running without GUI. Many PCs have a GUI only for the dumb user
who works with only the single program they know of - but when the
technican comes it kicks the GUI away to show the facts.

But most of all them above are programmed in C.

 

[The Real OS/2 Guy]

It's only likely to succeed if it can protect the user from needing to use
the command shell. I can't use it since I need to run programs that only
work on Windows.

Ever when I have to use windows I have to use its console to get the
results I need quickly instead looking for looooong time on flying
things like folders or documents. Doing the same work on commandline
lets me get finished it long before the windows GUI ever has done the
first step.

Oh, yeah, on my OS I can use the GUI because it is more quickly, more
elegant, more solid. But even there it lefts administrative work done
better on commandline. That is because it costs more time to fire the
GUI program up and click around its GUI than simply start an (GUI)
editor from commandline giving it the file to edit as parameter. In
that case the GUI is for the dumb user who does not know what he is
doing and the flat file is for the expert - but the result would be
the same.

The dumb user will use a day to get it done by clicking though the GUI
- I use 5 minutes for the same by editing some lines in some
configuration files.

Oh, yes - windows is for dumb users only. Even an expert has too often
no chance to work quickly and more exact as the dumb wincrap GUI
allows.

 

[The Real OS/2 Guy]

Still in full agreement. Surely this can't last?

NOT using the GUI of the compiler still speeds up the build process
significantly. When you've learned how to use make, your text editor
(GUI - but full flagged for the use as developer tool) you would never
miss the GUI until you have to run your GUI program. Oh, yeah, a GUI
driven debug may help you significantly to debug your multithreaded
(non)GUI application.

Okay, so where in that lot do I use my routines to connect to, or disconnect
from, an SMTP server? Ah...

find dev -name \*.c | xargs grep SMTP[CD]

Using Windows "find" we can look for files or folders named "myprog.exe",
and the GUI leads us through it.

Yes, and it's *slow*. What's more, it's harder to use than a CLI (IMHO,
having tried both).

I use both for finding something - depending on the kind of work I
have to do. When you use a good GUI (windows ones is cramp) you ends
up in both cases exactly w3ith that you want. If you uses a good
command processor (not the DOS thing that comes with windoes - but an
intelligent one like sh or 4os2) and you have a brain then it would be
easy.

Doesn't sound very scriptable to me.

Right - but often enough it would exactly fullify your needs. Else you
would use your commandline processor and its tools - when you're not
playing on windows.

However you do lose some flexibility -
you can't pipe to your own version of "sort" which handles numerical
values as numbers (so x2 is before x11), for instance.

That's not the only flexibility you lose.

It's only likely to succeed if it can protect the user from needing to use
the command shell.

On the contrary, it has already succeeded. Incidentally, just like Windows,
it gives the user the *choice* of a powerful[1] command shell, or a weak
but pretty GUI.

And now we come to the point of truth. Use eComStation to get both - a
powerfull shell which you can exchange to others when you likes and a
powerfull GUI that can be extended easy by lots of frewware tools and
by yourself as a prograsmmer.

[1] The default Windows command shell is nowhere near as powerful as Linux's
various shells, IMHO, but hey, you can always use Cygwin.

No wounder it is the same as you had with DOS, nothing new, too less
tools, too high limited.

Why not do the world a favour and port them to Linux?

Why not use eComStation and use them without porting? There is an open
source tool that migrates windows programms (NT, 2K, XP) on the fly
and lets them run seamless. There are already any usefull linux
commandline tools and shells ported to be native eComStation
applications, including apache, perl, php... and least but not last
anything you need to develop C programs.

 

[Robert Bachmann]

The real answer is that stdin is seldom used in real programs.

^^^^ ^^^^
The world is not only black and white, so it would be hard to give an
*real* answer.

-Robert

 

[The Real OS/2 Guy]

Pray tell me, how /do/ you send an text without typing?

Switch your microphone on, start up voice type, navigate your GUY by
speaking to your computer, let it open your preferred word
processor/mail program and dictate the text and formatting, order it
to print the document, read it, navigate with voice inside the text,
command the correctios, command it to save the document or to mail it
to its destination.

It can be done since 1996.

 

[The Real OS/2 Guy]

Actually system administrators hate GUI's because they (sysadmins)
sometimes have to do the same thing over and over to many computers, and
what they really want is a way to script the action, while still allowing
a certain number of intelligent variables.

This is why Microsoft is now working on the shell to beat all shells.
(We'll se if they succeed, but they have recognized the deficit and are
trying to fix it.)

Microsoft was saying the same more than 10 years ago. It repeats that
every year new but was never able to get it right. It had the chance
to come nearly that what OS/2 2.0 had done 11 years ago - but failed
even with XP to come nearly on that what OS/2 had brought.

Yeah, but they are not wintel boxes, either, which is the claim you seem
to be trying to contradict.

Anyway, don't forget about routers and access points and so on. Behind the
scenes, they absolutely use command lines.

And don't forget about all the embedded systems that don't really have a
user interface at all. Processors in cars, for example.

Besides, a lot of people like command lines. I'm one of them. ;-)

Me too - but my system gives me the best of both worlds at once. I use
the GUI extensively - but commandline whenever it is more effective.

Currently I use a system with 512 MB RAM, 4 GUI applications and 8
command windows active beside some desktop objects spreaded over 4
virtual desktops - and have about 256 MB RAM free. No, its not
windows, its not linux - but a PC where both are installed and
bootable when I may need them.

 

[Malcolm]

We've seen you knows nothing about real computeing.
[ snip ]

No, I don't use M$ software because M$ has proven itself to be
incompatible to anything - even to itself even in standard C.

I rest my case.