Erradicating a Buffer Overflow

[Peter Nilsson]

... I am under the impression, perhaps, that scanf and such
functions have at them a group of people who are in at least
partially strong objection to their use? If so, is their some
history or methods or something else about these scanf tools
with which I am not familar that has earned them such apparent
dislike?

The problem lies with teachers and tutors who are too eager to
teach the entire language as quickly as possible, without focussing
on details. You'll often see newbies totally unaware of the basic
problems with code like...

scanf("%s", my_string);
...

The problem with scanf is that it is too easy to misuse, especially
if you're just using 'default' options. Of course, that doesn't mean
it can't be used correctly. It just means that people are prone to
prefering alternative tools.

Unfortunately, writing bullet proof input routines that deal with
both good and bad input robustly (without undefined behaviour), and
which are able to continue with further input (in the absense of EOF),
is not a trivial task in C!

 

[Richard Bos]

In some regards, I feel almost as though having asked this question has
earned me even the slightest bit of disdain from some particular readers
of this group.

Some particular readers, undoubtedly. But you might read the group for a
bit longer before deciding how much to worry about Mr. SM "Could not
quote properly for his life" Ryan's opinion of yourself. As for me, I
feel no disdain for you.

Richard

 

[Mabden]

I suppose I should say that I am unsure of what other tools in the
Standard C Library allow me to extract, in one function call, all the date
information from a string that I need, in such a straightforward

fashion.

So write a function of your own. Duh.

If there is, I'd love to hear it. I personally came accross a sample
usage of sscanf in documentation, and found that it was much faster
compared to my original idea of single character stepping through the date
string.

Faster is so 1960's. You can't tell what is "faster" by looking at code.
Are you writing code for a microwave oven? If you code is for a modren
CPU then a good compiler will probably modify your code into something
fast. If you detect a slowdown, or want to, then run a profiler. No one
(except Gods - who may post here from time to time) can predict a
speedup - things you do to speed up your code may prevent the compiler
from speeding up your code. Just write code that solves the problem.

 

[Dave Thompson]

On Mon, 24 Oct 2005 10:09:52 -0400, "Arctic Fidelity"

sscanf(argv[1],
"%.3s, %d %.3s %4d %.8s %s",

<snip: various args ending with junk which is char[10]>

Those should be %3s etc. "Dot" numbers in *scanf are nonstandard. (Cf.
*printf where %Ns pads to minimum and %.Ns truncates to maximum.)

As you can guess, this is designed to take a specifically formatted date
string and read it into variables. However, in the date format I am
processing (mbox/overview file type dates), there is an extra bit after
the time that could be an arbitrary length. Generally, it's not bigger
than 10, which is why I initially used that value, but it did not click in
my head before that this would cause a problem. Then, while I was thinking
about it today, I realized that you could put in more than 10 characters
after the time section of the string, and overflow the program. My
question is, what is the proper way of handling this? How can I remedy it?

As already answered, the real answer is %*s or nothing, but one nit:

I could change %s to %.9s or something of that nature, but that would be
ugly, because I would end up with a bunch of whitespace and padding at the
beginning or the end. <snip>

*scanf %s, with or without a length limit, will always skip leading
whitespace and stop at following whitespace, so even if the supplied
string (which you said later isn't really an argv[] string) contains
padding this particular format wouldn't put it in the variable.

- David.Thompson1 at worldnet.att.net