26
votes

The following program prints the same number twice on gcc 4.8.2:

#include <stdio.h>

int main()
{
    char a[13];
    printf("sizeof a  is %zu\n", sizeof a );
    printf("sizeof(a) is %zu\n", sizeof(a));
}

According to this reddit post, gcc is not standard-conformant in this respect, because a parenthesized expression is not on the list of exceptions for when array-to-pointer decay does not happen.

Is this guy correct? Here is the relevant standard quote:

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

Just to be clear, he argues that (a) should trigger array-to-pointer decay, because parentheses are not covered in the list above (sizeof operator, unary & operator, string literal as initializer).

2
No, that guy is seriously confused - M.M
In his own words, I would agree with terminally confused - chqrlie
I haven't dealt this this stuff for about 15 years, but I'm definitely recalling a scenario with, I think, sizeof where the presence or absence of parentheses was significant -- determined if you were taking the size of the pointer or the size of the element, or something like that. - Hot Licks
Now I'm confused. What exactly is the purpose of that code? What are you expecting to get back from your sizeof expressions? The length of the array? But you KNOW that. The size of a char? Then why not sizeof (char)? The size of a pointer, since arrays basically are pointers? - jamesqf
@jamesqf I want to know if putting an array into parentheses triggers array-to-pointer decay. - fredoverflow

2 Answers

26
votes

Whether seemingly redundant parentheses affect the semantics of a program is a long-standing issue in the C standard that still hasn't been adequately resolved.

It is commonly claimed that ((void*)0) is technically not a null pointer constant, because there is no rule that says a parenthesised null pointer constant is a null pointer constant.

Some compilers issue an error for char s[] = ("abc");, because while a character array can be initialised from a string literal, that rule doesn't cover parenthesised string literals.

There are many similar examples. You've found one of them.

From what I can tell, the concensus is basically that the rule should be what C++ does, but what C never formally adopted. C++ makes a parenthesised expression functionally equivalent to the non-parenthesised expression, with a few explicitly-stated exceptions. This would cover all those issues at once.

So technically, the guy could be considered correct, but it's an overly strict interpretation of the standard that nobody really follows, since it's common knowledge that the standard is simply faulty here.

21
votes

From C99, 6.5.1, on parenthesized expressions:

Its type and value are identical to those of the unparenthesized expression.

At first glance, it would appear that this conflicts with the exception list you're referring to (6.3.2.1):

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"...

However, this list is in the context of operators/operands; parentheses don't appear to be deemed an operator (based on the categorisation implied by the structure of section 6.5).