Snafuist

Hello everyone,

there seem to be a lot of questions on this board regarding the correct use of scanf(), most of which advert to a weak understanding of pointers.

Personally, I haven't been using scanf() since I passed the initial 20 pages of my first book on C about ten years ago. Since then, I've always been using a (possibly dynamic) array to read data one character at a time and then check the input using isdigit(), atoi(), strtod(), whatever.

I think the underlying problem with scanf() is that it frequently appears early in the literature, way before the infamous chapter about pointers. At this point, the reader isn't familiar with the concept of a variable as the 4-tupel consisting of name, value, address and size and thus must regard the &-operator as some magic that is required to get scanf() to work as intended.


What's your opinion about the usefulness of scanf()?
Are you actually using it on a frequent basis?

Greets,
Philip

__________________
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip

Bladactania

I use it very rarely. The method I use depends on what I'm coding, but I agree with what you say. The only thing I use it for regularly is a "press enter when ready" situation.

MK27

I would almost echo your thoughts except my timeframe is like ten months and not ten years. But I also got taken in by GNU getline() which works quite well. After I while I started using my own little getline() like functions which work byte by byte, as you say, and this DEFINATELY is the most optimized and tweakable way to deal with input.

But there's nothing wrong with scanf or sscanf or fscanf. Specific criticisms of specific books, I have lots of those too I suppose I didn't bother much with the "scan" functions 'til I did get a real grip on pointers.

__________________

"A man can't just sit around." -- Larry Walters

Adak

I use scanf() to read in "clean" data that the program has produced in another function. For helping students, it seems to be necessary as well. I believe it's the fastest method to read data if you know it's absolutely formatted properly.

Otherwise, I stick with fgets(), into a buffer, and test it from there.

tabstop

I'm with Adak -- if I'm reading formatted data (often programmatically generated), then scanf is ideal. If I'm doing something quick in class on the big screen, I'll often use it there rather than find/create/import a whole input-verification suite. (Actually, usually I'm in C++ so it's >>, but same moral difference.) But for "real" user input, line-by-line is the way to go.

Snafuist

I should have mentioned that I don't believe in correctly formatted data except when I created it myself 5 minutes ago. In this case I refer to Perl, sh, bintools or whatever quick solution is available. A given format specification might have been correct on a particular Tuesday of last year, but in order to build stable code, I don't trust anyone (including me) stating that his output will always look like this-and-that.

__________________
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip

matsp

It is all about horses for courses. If you have file-data that is (supposedly) machine generated, then reading it with fscanf() is perfectly file - just check that the result is what you expect from the return value.

For simple programs that do not need much input-validation, it is also fine.

But for proper user-input, better methods are indeed necessari. strtol() is better than atol or atoi, in my opinion, as it allows you to detect both overflow and "extra garbage at the end" - and you can control the base if you wish too.

It serves it purpose as a simple method for input, but as stated, it is very easy to get it wrong in various ways, including user input that "blocks" any further input.

--
Mats

__________________
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

brewbuck

The majority of problems I see on this board related to scanf() are related to leaving junk in the buffer after a failed conversion, not pointer issues.

While one can learn how to properly use pointers, it is not possible by simply wishing, to cause scanf() to become a properly useful function.

__________________
"Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot

Meldreth

there's nothing wrong with magic. i don't think pointers need to be introduced to explain scanf. just say that every variable except an array gets prepended with '&' and the reason why will be made clear later. you don't have to understand a rule to memorize and follow it.

i use scanf all the time. there's no reason to use fgets and atoi when scanf is shorter, simpler and does what i want.

brewbuck

So how do you recover cleanly from malformatted inputs? Or do you just neglect input validation?

__________________
"Congratulations on your purchase. To begin using your quantum computer, set the power switch to both off and on simultaneously." -- raftpeople@slashdot

Meldreth

the same way i recover with other methods. if the input is malformed, ask for it again. it's not rocket science.

Elysia

The problems with scanf is that it requires a lot knowledge to use securely and without hitches.
Input validation must be done, buffer cleaning must be done, etc. So I believe it's not as much pointer issues, but generally a lack of know-how to properly use it. But you could argue that most who have problems with it simply ignored most of what they learned simply because it can be difficult to know everything. C is a difficult language, especially for beginners.
So I would partly lay blame on the books (because there are lot of bad ones out there) and partly on newbies who do not fully understand C. You could also lay blame on poor teachers. We've seen that happen, too.

__________________
Using: Microsoft Windows™ 7 Professional (x64), Microsoft Visual Studio™ 2008 Team System
I dedicated my life to helping others. This is only a small sample of what they said:
"Thanks Elysia. You're a programming master! How the hell do you know every thing?"
Quoted... at least once.

matsp

Further, scanf() doesn't play well with other input methods, e.g. fgets() or getchar(), since it leaves the terminating character(s) in the input buffer. This in itself is a very good reason for using fgets() for everything, if fgets() is ever needed in the code. If you still like to use scanf(), then use fgets() + sscanf(),

--
Mats

__________________
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.

Snafuist

I do. But as far as I can tell, this is the only easy way to make a beginner able to read input data. The standard library lacks simple input functions like e.g. getdouble(), getint() and so on, which is what my rant on scanf() is all about: I don't like scanf() because it's kind of an all-in-one wonder function, but what really disturbs me is the fact that there is no simple standardized alternative. If you're already familiar with the complexity of scanf(), input buffers and the like, then it seems natural to say scanf("%d", &n) to read an int and having to check the return value, but for a beginner, this has to look like voodoo. Now, C's goal is probably not to be friendly to beginners, but I can also see issues here concerning efficiency and design. If you were to write a function to read input, would you choose char* and "..." as its arguments?

brewbuck, I don't get your point, but this is maybe due to my poor English skills. To me, it seems that you regard scanf() to be not properly useful, is that right?

Greets,
Philip

__________________
All things begin as source code.
Source code begins with an empty file.
-- Tao Te Chip

Bladactania

Really? You're probably one of the better English speaking people here!