scanf() consideres useless

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

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.

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.

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.

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.

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.

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

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.

Quote:

---

Originally Posted by Snafuist

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.

---

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.

Quote:

---

Originally Posted by Meldreth

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.

---

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

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

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.

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

Quote:

---

you don't have to understand a rule to memorize and follow it.

---

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?

Quote:

---

it is not possible by simply wishing, to cause scanf() to become a properly useful function.

---

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

Quote:

---

Originally Posted by Snafuist

I don't get your point, but this is maybe due to my poor English skills.

---

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

As you say, C was not written to be a "begginers language". With a little bit of experience, you can certainly write a funciton that does "getInt" or "getDouble".

scanf() is a bit of a swiss-army-knife, tries to do many different things, and in doing so, does most of them rather badly. But it is also very powerful, because you can read all sorts of interestingly formatted input with it. For example, a : separated list of username and userid can be read by:

Code:

---

scanf("%s:%d", name, &id);

---

And as to changing it, it won't happen any time soon. scanf() has been part of the C language since it became published (in the original K&R -non-ANSI edition), and it's unlikely to be replaced by something better anytimes soon.

C++ is a little bit user friendlier here, with the cin >> x;

As to the choice of using a char * format string and variable arguments, well, I'm sure we can come up with many different solutions. None of them will be perfect. The only other flexible model would be an array of "descriptors" - each describing one element of input, where to store that and how it is formatted. I don't think that's better.

Using many individual calls to getInt, etc, etc, would be less space-efficient. Perhaps not important today, but in the time when C was invented, saving space was critical - after all, machines would have kilobytes of memory available to a process - not mega- or gigabytes.

--
Mats