From man gets
:
Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.
Almost everywhere I see scanf
being used in a way that should have the same problem (buffer overflow/buffer overrun): scanf("%s",string)
. This problem exists in this case? Why there are no references about it in the scanf
man page? Why gcc does not warn when compiling this with -Wall
?
ps: I know that there is a way to specify in the format string the maximum length of the string with scanf
:
char str[10];
scanf("%9s",str);
edit: I am not asking to determe if the preceding code is right or not. My question is: if scanf("%s",string)
is always wrong, why there are no warnings and there is nothing about it in the man page?
You should not use gets since it has no way to stop a buffer overflow. If the user types in more data than can fit in your buffer, you will most likely end up with corruption or worse.
The problems with scanf are (at a minimum): using %s to get a string from the user, which leads to the possibility that the string may be longer than your buffer, causing overflow. the possibility of a failed scan leaving your file pointer in an indeterminate location.
In C11, the famous gets function is removed. The gets function was subject to buffer overflow attacks, and in older versions it was decided to make the function deprecated. Later, as part of the C11 standard, it was removed.
To avoid Buffer Overflow, fgets() should be used instead of gets() as fgets() makes sure that not more than MAX_LIMIT characters are read.
The answer is simply that no-one has written the code in GCC to produce that warning.
As you point out, a warning for the specific case of "%s"
(with no field width) is quite appropriate.
However, bear in mind that this is only the case for the case of scanf()
, vscanf()
, fscanf()
and vfscanf()
. This format specifier can be perfectly safe with sscanf()
and vsscanf()
, so the warning should not be issued in that case. This means that you cannot simply add it to the existing "scanf-style-format-string" analysis code; you will have to split that into "fscanf-style-format-string" and "sscanf-style-format-string" options.
I'm sure if you produce a patch for the latest version of GCC it stands a good chance of being accepted (and of course, you will need to submit patches for the glibc header files too).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With