Semantics of char a[]

Question

I recently embarrassed myself while explaining to a colleague why

char a[100];
scanf(\"%s\", &a); // notice a & in front of \'a\'

is ve

Answer 1

Well, scanf expects a char* pointer as the next argument when seeing a "%s". But what you give it is a pointer to a char[100]. You give it a char(*)[100]. It's not guaranteed to work at all, because the compiler may use a different representation for array pointers of course. If you turn on warnings for gcc, you will see also the proper warning displayed.

When you provide an argument object that is an argument not having a listed parameter in the function (so, as in the case for scanf when has the vararg style "..." arguments after the format string), the array will degenerate to a pointer to its first element. That is, the compiler will create a char* and pass that to printf.

So, never do it with &a and pass it to scanf using "%s". Good compilers, as comeau, will warn you correctly:

warning: argument is incompatible with corresponding format string conversion

Of course, the &a and (char*)a have the same address stored. But that does not mean you can use &a and (char*)a interchangeably.

---

Some Standard quotes to especially show how pointer arguments are not converted to void* auto-magically, and how the whole thing is undefined behavior.

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. (6.3.2.1/3)

So, that is done always - it isn't mentioned below explicitly anymore when listening valid cases when types may differ.

The ellipsis notation in a function prototype declarator causes argument type conversion to stop after the last declared parameter. The default argument promotions are performed on trailing arguments. (6.5.2.2/7)

About how va_arg behaves extracting the arguments passed to printf, which is a vararg function, emphasis added by me (7.15.1.1/2):

Each invocation of the va_arg macro modifies ap so that the values of successive arguments are returned in turn. The parameter type shall be a type name specified such that the type of a pointer to an object that has the specified type can be obtained simply by postfixing a * to type. If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:

• one type is a signed integer type, the other type is the corresponding unsigned integer type, and the value is representable in both types;
• one type is pointer to void and the other is a pointer to a character type.

Well, here is what that default argument promotion is:

If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. (6.5.2.2/6)