#include <stdio.h>
#define a (1,2,3)
#define b {1,2,3}
int main()
{
unsigned int c = a;
unsigned int d = b;
printf("%d\n",c);
printf("%d\n",d);
return 0;
}
Above C code will print output as 3 and 1.
But how are #define a (1,2,3) and #define b {1,2,3} taking a=3 and b=1 without build warning, and also how () and {} are giving different values?
Remember, pre-processor just replaces macros. So in your case you code will be converted to this:
#include <stdio.h>
int main()
{
unsigned int c = (1,2,3);
unsigned int d = {1,2,3};
printf("%d\n",c);
printf("%d\n",d);
return 0;
}
In first case, you get result from , operator, so c will be equal to 3. But in 2nd case you get first member of initializer list for d, so you will get 1 as result.
2nd lines creates error if you compile code as c++. But it seems that you can compile this code in c.
In addition to other answers,
unsigned int d = {1,2,3};
(after macro substitution)
is not valid in C. It violates 6.7.9 Initialization:
No initializer shall attempt to provide a value for an object not contained within the entity being initialized.
With stricter compilation options (gcc -std=c17 -Wall -Wextra -pedantic test.c), gcc produces:
warning: excess elements in scalar initializer
unsigned int d = {1,2,3};
^
However, note that
unsigned int d = {1};
is valid because initializing scalar with braces is allowed. Just the extra initializer values that's the problem with the former snippet.
For c, the initializer is an expression, and its value is 3. For d, the initializer is a list in braces, and it provides too many values, of which only the first is used.
After macro expansion, the definitions of c and d are:
unsigned int c = (1,2,3);
unsigned int d = {1,2,3};
In the C grammar, the initializer that appears after unsigned int c = or unsigned int d = may be either an assignment-expression or { initializer-list } (and may have a final comma in that list). (This comes from C 2018 6.7.9 1.)
In the first line, (1,2,3) is an assignment-expression. In particular, it is a primary-expression of the form ( expression ). In that, the expression uses the comma operator; it has the form expression , assignment-expression. I will omit the continued expansion of the grammar. Suffice it to say that 1,2,3 is an expression built with comma operators, and the value of the comma operator is simply its right-hand operand. So the value of 1,2 is 2, and the value of 1,2,3 is 3. And the value of the parentheses expression is the value of the expression inside it, so the value of (1,2,3) is 3. Therefore, c is initialized to 3.
In contrast, in the second line, {1,2,3} is { initializer-list }. According to the text in C clause 6.7.9, the initializer-list provides values used to initialize the object being defined. The { … } form is provided to initialize arrays and structures, but it can be used to initialize scalar objects too. If we wrote unsigned int d = {1};, this would initialize d to 1.
However, 6.7.9 2 is a constraint that says “No initializer shall attempt to provide a value for an object not contained within the entity being initialized.” This means you may not provide more initial values than there are things to be initialized. Therefore, unsigned int d = {1,2,3}; violates the constraint. A compiler is required to produce a diagnostic message. Additionally, your compiler seems to have gone on and used only the first value in the list to initialize d. The others were superfluous and were ignored.
(Additionally, 6.7.9 11 says “The initializer for a scalar shall be a single expression, optionally enclosed in braces.”)
Consider the following struct initialization:
#include<stdio.h>
struct bar {
int b;
int a;
int r;
};
struct foo {
struct bar bar;
};
int main(int argc, char **argv) {
struct bar b = {1, 2, 3};
struct foo f = {.bar = b, .bar.a = 5 };
// should this print "1, 5, 3", "1, 5, 0", or "0, 5, 0"?
// clang on Mac prints "1, 5, 3", while gcc on Ubuntu prints "0, 5, 0"
printf("%d, %d, %d\n", f.bar.b, f.bar.a, f.bar.r);
return 0;
}
The C11 standard seems to do a quite poor job of describing what behavior should be expected here in section 6.7.9, but seems to think it's doing a reasonable job, as I don't see any warnings regarding undefined behavior in this case either.
In practice, it seems the behavior is either not standardized or the standard is violated by at least one common compiler, with clang/llvm 8.0.0 on a Mac producing "1, 5, 3", and gcc 5.4 on Ubuntu producing "0, 5, 0".
According to the C standard, should f.bar.b and f.bar.r well defined at this point, or does this initialization result in undefined or unspecified behavior?
The C11 standard seems to do a quite poor job of describing what behavior should be expected here in section 6.7.9,
Standardese can be difficult to read, but I don't think this area of the standard is worse in that respect than should be expected.
but seems to think it's doing a reasonable job, as I don't see any warnings regarding undefined behavior in this case either.
The standard is not required to explicitly declare undefined behaviors. Indeed, the standard contains a blanket statement that wherever it does not define behavior for a given piece of code, that code's behavior is undefined. Nevertheless, I do think section 6.7.9 covers this area pretty thoroughly. The main area left open is this:
The evaluations of the initialization list expressions are indeterminately sequenced with respect to one another and thus the order in which any side effects occur is unspecified.
(C2011, 6.7.9/23)
That doesn't present any problem for your example.
In practice, it seems the behavior is either not standardized or the standard is violated by at least one common compiler, with clang/llvm on a Mac producing "1, 5, 3", and gcc on Ubuntu producing "0, 5, 0".
I'm completely prepared to believe that one or the other of those is non-conforming in this area. However, do also pay attention to compiler versions and compilation options -- they may be compiling for different versions of the standard, with or without extensions.
According to the C standard, should f.bar.b and f.bar.r well defined at this point, or does this initialization result in undefined or unspecified behavior?
If the declaration of an object has an associated initializer then the whole object is initialized, and furthermore, the resulting initial value is well-defined by the standard, subject to caveats arising from 6.7.9/23. As for the initial values required of a conforming implementation in your example, the key provisions are these:
The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.
(C2011, 6.7.9/19; emphasis added)
Each designator list begins its description with the current object associated with the closest surrounding brace pair. Each item in the designator list (in order) specifies a particular member of its current object and changes the current object for the next designator (if any) to be that member. The current object that results at the end of the designator list is the subobject to be initialized by the following initializer.
(C2011, 6.7.9/18; emphasis added)
If the aggregate or union contains elements or members that are aggregates or unions, these rules apply recursively to the subaggregates or contained unions.
(C2011, 6.7.9/20)
Thus, given f's initializer,
struct foo f = {.bar = b, .bar.a = 5 };
we first process element .bar = b, as required by 6.7.9/19. That contains a designator list designating foo.b, of type struct bar, as the object to initialize from the following initializer. This initializer exercises the option of being "a single expression that has compatible structure or union type", per 6.7.9/13, therefore the initial value of f.bar is the value of b, subject to partial or full override by subsequent initializers.
We next process the second element, .bar.a = 5. This initializes f.bar.a and only that subobject, per 6.7.9/18, overriding the initialization specified by the previous initializer per 6.7.9/19.
The result of conforming initialization thus leads to printing
1, 5, 3
GCC seems to be failing by re-initializing all of f.bar when it processes the the second initializer, instead of only f.bar.a.
In the C Standard there is written (6.7.9 Initialization)
17 Each brace-enclosed initializer list has an associated current
object. When no designations are present, subobjects of the current
object are initialized in order according to the type of the current
object: array elements in increasing subscript order, structure
members in declaration order, and the first named member of a
union.148) In contrast, a designation causes the following initializer
to begin initialization of the subobject described by the designator.
Initialization then continues forward in order, beginning with the
next subobject after that described by the designator
And
19 The initialization shall occur in initializer list order, each
initializer provided for a particular subobject overriding any
previously listed initializer for the same subobject;151) all
subobjects that are not initialized explicitly shall be initialized
implicitly the same as objects that have static storage duration.
This footnote is important
148) If the initializer list for a subaggregate or contained union
does not begin with a left brace, its subobjects are initialized as
usual, but the subaggregate or contained union does not become the
current object: current objects are associated only with
brace-enclosed initializer lists.
Thus I see neither undefined nor unspecified behavior.
In my opinion the result should look like { 1, 5, 3 }.
If to leave aside the Standard then it is reasonable at first to initialize the memory with the default initializes and then overwrite it with the explicit initializers.
The standard says…
I'm going to quote from §6.7.9 Initializers of ISO/IEC 9899:2011 (the C11 standard), the same section as Vlad from Moscow quotes in his answer:
¶16 Otherwise, the initializer for an object that has aggregate or union type shall be a brace-enclosed list of initializers for the elements or named members.
¶17 Each brace-enclosed initializer list has an associated current object. When no designations are present, subobjects of the current object are initialized in order according to the type of the current object: array elements in increasing subscript order, structure members in declaration order, and the first named member of a union.148) In contrast, a designation causes the following initializer to begin initialization of the subobject described by the designator. Initialization then continues forward in order, beginning with the next subobject after that described by the designator.149)
¶18 Each designator list begins its description with the current object associated with the closest surrounding brace pair. Each item in the designator list (in order) specifies a particular member of its current object and changes the current object for the next designator (if any) to be that member.150) The current object that results at the end of the designator list is the subobject to be initialized by the following initializer.
¶19 The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject;151) all subobjects that are not initialized explicitly shall be initialized implicitly the same as objects that have static storage duration.
¶20 If the aggregate or union contains elements or members that are aggregates or unions, these rules apply recursively to the subaggregates or contained unions. If the initializer of a subaggregate or contained union begins with a left brace, the initializers enclosed by that brace and its matching right brace initialize the elements or members of the subaggregate or the contained union. Otherwise, only enough initializers from the list are taken to account for the elements or members of the subaggregate or the first member of the contained union; any remaining initializers are left to initialize the next element or member of the aggregate of which the current subaggregate or contained union is a part.
¶21 If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.
148) If the initializer list for a subaggregate or contained union does not begin with a left brace, its subobjects are initialized as usual, but the subaggregate or contained union does not become the current object: current objects are associated only with brace-enclosed initializer lists.
149) After a union member is initialized, the next object is not the next member of the union; instead, it is the next subobject of an object containing the union.
150) Thus, a designator can only specify a strict subobject of the aggregate or union that is associated with the surrounding brace pair. Note, too, that each separate designator list is independent.
151) Any initializer for the subobject which is overridden and so not used to initialize that subobject might not be evaluated at all.
Interpretation
I think your code is well-formed and that GCC is handling it incorrectly and Clang is handling it correctly.
With your code modified only so that the unused argc and argv are replaced by void, running on a Mac with macOS Sierra 10.12.1, compiling with GCC 6.2.0 and with Apple's clang version 'Apple LLVM version 8.0.0 (clang-800.0.42.1)', I get the same results as you:
0, 5, 0 from GCC.
1, 5, 3 from Clang.
The key wording in the standard is:
In contrast, a designation causes the following initializer to begin initialization of the subobject described by the designator.
In your initializer, you have:
struct foo f = { .bar = b, .bar.a = 5 };
The first part of the initializer, .bar = b, clearly initializes the bar subobject. At that point, .bar.b has the value 1, .bar.a has the value 2, .bar.r has the value 3. If you omit the , .bar.a = 5 portion of the initializer, the compilers agree.
When you include the , .bar.a = 5, the designator causes the following initialize to begin intialization of the subobject described by the designator — and the designator is .bar.a so the initialization 5 initializes .bar.a. The compilers agree on this; both set .bar.a to 5. But the subobject designated by .bar was previously initialized, so the initializer for .bar.a only affects the .a element; it should not override any other element.
If the initializer is extended with with , 19, then the 19 is not a designation, but it initializes the subobject after the previous designation, which is .bar.r. Both the compilers agree with this.
This test code, a minor variant on your code, illustrates:
#include <stdio.h>
struct bar
{
int b;
int a;
int r;
};
struct foo
{
struct bar bar;
};
static inline void foobar(struct foo f)
{
printf("%d, %d, %d\n", f.bar.b, f.bar.a, f.bar.r);
}
int main(void)
{
struct bar b = {1, 2, 3};
struct foo f0 = {.bar = b, .bar.a = 5 };
struct foo f1 = {.bar = b, .bar.a = 5, 19 };
struct foo f2 = {.bar = b };
foobar(f0);
foobar(f1);
foobar(f2);
return 0;
}
The output from GCC is:
0, 5, 0
0, 5, 19
1, 2, 3
The output from Clang is:
1, 5, 3
1, 5, 19
1, 2, 3
Note that even with no warnings specifically enabled, clang gripes about this code:
$ clang -O3 -g -std=c11 so-4092-0714.c -o so-4092-0714
so-4092-0714.c:21:36: warning: subobject initialization overrides initialization of other fields within its
enclosing subobject [-Winitializer-overrides]
struct foo f0 = {.bar = b, .bar.a = 5 };
^~~~~~
so-4092-0714.c:21:29: note: previous initialization is here
struct foo f0 = {.bar = b, .bar.a = 5 };
^
so-4092-0714.c:22:36: warning: subobject initialization overrides initialization of other fields within its
enclosing subobject [-Winitializer-overrides]
struct foo f1 = {.bar = b, .bar.a = 5, 19 };
^~~~~~
so-4092-0714.c:22:29: note: previous initialization is here
struct foo f1 = {.bar = b, .bar.a = 5, 19 };
^
2 warnings generated.
$
As I said, I think Clang is initializing these structures correctly, even if it complains more than necessary while doing so.
This is not undefined behavior.
From section 6.7.9 of the C standard:
19 The initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding
any previously listed initializer for the same subobject; all
subobjects that are not initialized explicitly shall be initialized
implicitly the same as objects that have static storage duration.
So when there is a conflict among designated initializers, the last one listed takes precedence.
In your example, you initialize .bar, then .bar.b. Both of these initialize .bar, so the second one is used. So .bar is initialized, along with its subfield .bar.b, but not .bar.a or .bar.r. And because some fields are initialized but not all, the others are initialized to 0:
21 If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in
a string literal used to initialize an array of known size than
there are elements in the array, the remainder of the
aggregate shall be initialized implicitly the same as objects that
have static storage duration.
This means that the correct behavior is to output "0,5,0". So gcc is conforming and the Mac compiler is not.
Since this question was posted, the C18 standard has been released, and includes some additional clarifications that make the answer completely clear.
A clarification request similar to this question had been asked of the standards body as early as 2012, with some changes to the language being briefly discussed that might make the meaning clearer...ultimately it was decided that the C11 language was already correct, but that an example should be added to clarify.
Example 12 in section 6.7.9 of the last publicly available C17 draft demonstrates the correct behavior when a subobject is fully and then partially initialized, noting that any trailing values of the larger subobject not explicitly overwritten should survive (rather than be overwritten by default values), "because implicit initialization does not override explicit initialization."
So the correct behavior is to print "1, 5, 3".
I've been hunting around on why this compiles:
struct x_ {
char a[10];
int b;
};
struct x_ tmp = {{{{0}}}};
We may have an older gcc version, so {0} may not work and {{0}} should be used, but don't see this {{{{0}}}} anywhere.
See gcc bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
Thanks
Peter
I interpret the question to be asking whether GCC is correct to accept the specified initializer for an object of the specified type. To address the question I will be quoting from section 6.7.9 of the C2011 standard.
In the first place, the following applies both to the initializer for the overall struct and to the initializer within for the first member:
[...] the initializer for an object that has aggregate or union type shall be a brace-enclosed list of initializers for the elements or named members.
We then have:
Each brace-enclosed initializer list has an associated current object. [...] subobjects of the current object are initialized in order according
to the type of the current object: array elements in increasing subscript order, structure members in declaration order [...].
... and later ...
If the aggregate or union contains elements or members that are aggregates or unions, these rules apply recursively to the subaggregates or contained unions. If the initializer of a subaggregate or contained union begins with a left brace, the initializers enclosed by that brace and its matching right brace initialize the elements or members of the subaggregate or the contained union.
Among those, we have the overall {{{{0}}}} established as an initializer for the whole struct, {{{0}}} as an initializer for its first member, a, and {{0}} as an initializer for a[0]. The question comes down to whether the last pairing is a valid. If it is, then the others are valid, too.
This possibly bears on the matter:
The initializer for a scalar shall be a single expression, optionally enclosed in braces.
(emphasis added). That can be interpreted to specify that the initializer for a[0] can be enclosed in braces, i.e. as {0}, because a[0] is indeed a scalar. I am not convinced that that's the intended interpretation, but I would not be prepared at this point to fault GCC for accepting it.
I do not, however, accept {{0}} as a single expression enclosed in braces, therefore I do not accept it to be a valid initializer for a[0]. I speculate that GCC accepts it as a result of inappropriate recursive application of the rule allowing scalar initializers to be brace-enclosed.
For what it's worth, GCC 4.4.7 does emit two warnings about the construct by default:
i.c:7: warning: braces around scalar initializer
i.c:7: warning: (near initialization for ‘tmp.a[0]’)
i.c:7: warning: braces around scalar initializer
i.c:7: warning: (near initialization for ‘tmp.a[0]’)
Evidently, then, someone thought the extra braces were questionable, but the GCC documentation does not mention accepting that form among the supported language extensions. At minimum, then, there is a documentation bug.
When initializing a struct containing an array, you can either initialize the first element (with the rest set to 0 by default) or you can provide an initialization of each value. In this case using either a string initialization for a, or an array-style initialization providing a value for all members, e.g.
struct x_ tmp = { .a="" }; /* using string initialization of a */
or
struct x_ tmp = {{0},0}; /* using array initialization format */
Failing to identify a specific field, or provide an initialization for all members will generate compiler warnings for braces around a scalar initializer and missing-field-initializers, while initializing values to 0 by default.
Example with Use/Output
#include <stdio.h>
struct x_ {
char a[10];
int b;
};
int main (void) {
struct x_ tmp = { .a="" }; /* using string initialization of a */
struct x_ tmq = {{0},0}; /* using array initialization format */
printf ("\n tmp.a : '%s', tmp.b : %d\n", tmp.a, tmp.b);
printf ("\n tmq.a : '%s', tmq.b : %d\n", tmq.a, tmq.b);
return 0;
}
e.g.
$ ./bin/struct_init
tmp.a : '', tmp.b : 0
tmq.a : '', tmq.b : 0
I came across the below initialization , it is seen that VS2012
shows an error complaining about too many initializers. in GCC it seems to
return the first element as the value.
why is this peculiar initialization supported in GCC?
#include <stdio.h>
int main()
{
int q = {1,2};
char c = {'s','t','\0'}; /* c is 's' */
printf("%d\n",q); /* prints 1*/
}
C11: 6.7.9 Initialization (p11):
The initializer for a scalar shall be a single expression, optionally enclosed in braces.
Therefore, this is allowed
int q = {1};
You can enclose the initializer for scalar objects in braces ({}). Note the verb shall is used here. The standard says:
5.1.1.3 Diagnostics (P1):
A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined
So, it is up to the compiler how it handles
int q = {1,2};
Compiled on GCC 4.8.1 with flags -pedantic -Wall -Wextra and it raised a warning
[Warning] excess elements in scalar initializer [enabled by default]
Now the question is: What happend with the remaining initializers?
It's a bug.
Note: C11: 6.5.17 (p3) says that the comma operator cannot appear in contexts where a comma is used to separate items in a list (such as arguments to functions or lists of initializers).
Do not confused the , in {1,2} with comma operator. As Keith Thompson pointed out that, the expression in initializer to be an assignment-expression and it must not contain comma operator at top-level. That means it can be used within a parenthesized expression or within the second expression of a conditional operator in such contexts. In the function call
f(a, (t=3, t+2), c)
the function has three arguments, the second of which has the value 5.
This question already has answers here:
Initializing variable length array [duplicate]
(3 answers)
Variable-length arrays in C89?
(3 answers)
Closed 8 years ago.
#include<stdio.h>
main() {
int a=5;
int array[a]={0};
printf("Success\n");
}
when i am executing the program it will through a error as
b.c: In function ‘main’:
b.c:8:1: error: variable-sized object may not be initialized
b.c:8:1: warning: excess elements in array initializer [enabled by default]
b.c:8:1: warning: (near initialization for ‘array’) [enabled by default]
In cc complier . but i can assign like this
int array[5]={0};
If anyone correct me?
This statement
int array[a]={0};
declares a Variable Length Array (VLA).
According to C Standard (6.7.9 Initialization)
3 The type of the entity to be initialized shall be an array of
unknown size or a complete object type that is not a variable length
array type.
The problem is that the compiler shall know the array size at compile time that to generate the code that initialize an array.
Consider an example
void f( size_t n )
{
int a[n] = { 1, 2, 3, 4, 5 };
//...
}
Here is a is a variable length array. Now as n can have any value then the number of initializers in the array definition can be greater than the size of the array. So this code breaks the Standard from another side because the number of initializers may not be greater than the number of elements of array. On the other hand if the number of initializers less than the number of elements of array then what to do in this case? Maybe the programmer did not mean that some elements shall be zero-initialized.
As for this declaration
int array[5]={0};
then there is no variable length array. The size of the array is known at compile time. So there is no problem
.
"Variable-length automatic arrays are allowed in ISO C99, and as an
extension GCC accepts them in C90 mode and in C++"
says here.
Compilers can differ in some situations. It's normal to have problems with variable-sized arrays. This should work if you really need to do this
#include<stdio.h>
#DEFINE A 5
main()
{
int array[A]={0};
printf("Success\n");
}
The elements field within square brackets [], representing the number of elements in the array, must be a constant expression, since arrays are blocks of static memory whose size must be determined at compile time, before the program runs.