Thread: FAQ Clarification

Why gets() is bad / Buffer Overflows

In this FAQ, you state that "gets() has only received the name of the array (a pointer), it does not know how big the array is, and it is impossible to determine this from the pointer alone."

However, it IS possible to determine the number of elements in any array by using the sizeof keyword, at least in tests that I have conducted in Microsoft Visual C++ and Borland C++ Builder.

For example, the following code prints the number of elements of the array, line twice. Once using this method and the other using the constant value that was used to declare the array.

Source:

#include <stdio.h>
#define MAXLINE 100

int main(int argc, char *argv[])
{
char line[MAXLINE + 1]; /* Extra element for null character. */
int printed;

printed = printf("%u %u\n", MAXLINE, sizeof(line) / sizeof(*line));

return (printed == 7 ? 0 : 1);
}

Output:

101 101

I always thought that "sizeof" was a resolved by the compiler at the compile time. So it only works on structures and arrays with known values. It does not work with arrays such as "char *p" as it will not know how many char's "p" points to.

Therefore "sizeof" can not be used. There are no other ways to determine the length of an array from the pointer alone.

Oops, the output should read:

100 101

because the MAXLINE constant is 100 and will always be 100. Silly me.

>>I always thought that "sizeof" was a resolved by the compiler at the compile time.
With one exception,variable length arrays in C99.

Code:

int size;
scanf("%d",&size);
int array[size];
sizeof(array); //Runtime,not Compiletime

Knowning the size does you no good. Your user can still type whatever they want, regardless of the actual size

I'm talking about the fact that it is possible to know the length of a character array that is declared at compile time like, char array[50] using sizeof(array) / sizeof(*array).

I don't know what you're talking about! =)

Sure, you can find out for sure that the size is 2, but this doesn't prevent me from typing in 100 characters if I like.

I'm not saying it does. I'm just saying that gets can find out, but it doesn't care to.

So it only works on structures and arrays with known values.

So, it would'nt work if I malloc a character array dynamically, for example?

[QUOTE]there is nothing you can do here which will
// reliably tell you that p points to 100 bytes[QUOTE]

If the array was declared to be a 100 bytes at compile time as in your example, and you CAN use sizeof(buff) / sizeof(*buff) to reliably tell you the length than why would the pointer *p in your function be any different than buff?

Why is the buffer pointer in your function any different than the line pointer in main? The line pointer just gets passed to your function, where it is stored in the buffer pointer, they should be equal so why does sizeof return different results?

But I thought any time you use the name of an array it is interpreted as a pointer to that array.

>>But I thought any time you use the name of an array it is interpreted as a pointer to that array.

6.3.2.1 Lvalues, arrays, and function designators

Except when it is the operand of the sizeof operator or the unary & operator, or is a
string literal used to initialize an array, an expression that has type ‘‘array of type’’ is
converted to an expression with type ‘‘pointer to type’’ that points to the initial element of
the array object and is not an lvalue.

Originally posted by Wledge
>>But I thought any time you use the name of an array it is interpreted as a pointer to that array.

6.3.2.1 Lvalues, arrays, and function designators

Oh, I get it. Thanks for the reference to the ANSI C Standard. I guess I better go back to writing my getline function, which will properly get a line of input from the user and stop complaining about how crappy gets is. And while I'm at it maybe I'll reread the chapter on pointers in K & R's The C Programming Language.