Minimal working (or should I say non-working example)...

#include <stdio.h>
int main () {
int istest=1;
char op[8] = (istest?"ef":"df");
/*char op[8] = "ef";*/
printf("op=%s\n",op); }

for which cc emits the error...

test.c: In function 'main':
test.c:4:16: error: invalid initializer
4 | char op[8] = (istest?"ef":"df");
| ^

But if I comment out that line and uncomment the one below it,
then it compiles and runs fine. I've used this construction
a million times without problems. But a-million-and-one seems
to somehow be a problem. What's wrong???
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

John Forkosh <forkosh@panix.com> wrote:
.... and just to emphasize the point,
the following minimal now-working program compiles
and runs just fine

#include <stdio.h>
#include <string.h>
int main () {
int istest=1;
/*char op[8] = (istest?"ef":"df");*/
char op[8] = "ef";
strcpy(op,(istest?"df":"ef"));
printf("op=%s\n",op); }

So the (istest?"df":"ef") seems to be just fine,
as per my million-times-used expectations.
But the stoopid char op[8] = (istest?"ef":"df");
is somehow creating a problem that completely
baffles me.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

2022-01-25 at 13:00 -0000, John Forkosh wrote:
> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

I do not think that an array initializer can be a conditional
expression.

Are you sure that in your million previous times you were initializing
an array, and not a pointer? ie. this should work as you expect:

#include <stdio.h>
int main () {
int istest=1;
char *op = (istest?"ef":"df");
printf("op=%s\n",op);
}

Mateusz

On 25/01/2022 13:09, John Forkosh wrote:
> John Forkosh <forkosh@panix.com> wrote:
> ... and just to emphasize the point,
> the following minimal now-working program compiles
> and runs just fine
>
> #include <stdio.h>
> #include <string.h>
> int main () {
> int istest=1;
> /*char op[8] = (istest?"ef":"df");*/
> char op[8] = "ef";
> strcpy(op,(istest?"df":"ef"));
> printf("op=%s\n",op); }
>
> So the (istest?"df":"ef") seems to be just fine,
> as per my million-times-used expectations.
> But the stoopid char op[8] = (istest?"ef":"df");
> is somehow creating a problem that completely
> baffles me.

You're initialising an array of small integers. This would normally be
done with:

{'e', 'f'};

For an array of char, and for long strings, this would involve a lot of
typing. So C allows you to represent the list using a string:

"ef";

even though this has the wrong type (char*, not char[]). It's easy to
see that you're pushing it if you further try to incorporate that into
an expression. Partly because the expression has to yield a value-array
type (char[]), which is not possible in C.

The standards experts will be along shortly to tell you exactly which
sub-section and paragraph forbids it.

Meanwhile, try changing 'char op[8]' into 'char* op', and it should
work. Your version using strcpy is manipulating char* types not char[],
that's why it works.

Bart <bc@freeuk.com> wrote:
> On 25/01/2022 13:09, John Forkosh wrote:
>> John Forkosh <forkosh@panix.com> wrote:
>> ... and just to emphasize the point,
>> the following minimal now-working program compiles
>> and runs just fine
>>
>> #include <stdio.h>
>> #include <string.h>
>> int main () {
>> int istest=1;
>> /*char op[8] = (istest?"ef":"df");*/
>> char op[8] = "ef";
>> strcpy(op,(istest?"df":"ef"));
>> printf("op=%s\n",op); }
>>
>> So the (istest?"df":"ef") seems to be just fine,
>> as per my million-times-used expectations.
>> But the stoopid char op[8] = (istest?"ef":"df");
>> is somehow creating a problem that completely
>> baffles me.
>
>
> You're initialising an array of small integers. This would normally be
> done with:
>
> {'e', 'f'};
>
> For an array of char, and for long strings, this would involve a lot of
> typing. So C allows you to represent the list using a string:
>
> "ef";
>
> even though this has the wrong type (char*, not char[]). It's easy to
> see that you're pushing it if you further try to incorporate that into
> an expression. Partly because the expression has to yield a value-array
> type (char[]), which is not possible in C.
>
> The standards experts will be along shortly to tell you exactly which
> sub-section and paragraph forbids it.
>
> Meanwhile, try changing 'char op[8]' into 'char* op', and it should
> work. Your version using strcpy is manipulating char* types not char[],
> that's why it works.

Thanks, I know for sure I've used more-or-less this type
of construction a million times, and could've sworn I'd done it
exactly this way at least a few thousand, but apparently not.
And just to check your remarks, while the char op[8] = "ef";
initialization works, when I tried what you'd (or at least me'd)
think would be the same char op[8] = (char *)"ef";
then that emitted the same invalid initializer error.
No problem, I'll just use the strcpy. I usually allocate more
bytes than I actually need in these kinds of cases, just in case
an extra character or two slips in. So I don't personally like
the char *op= solution. Anyway, thanks again for clearing it up.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

John Forkosh <forkosh@panix.com> writes:

> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

What you've done is take a construct (the istest?"ef":"df"
subexpression) that works in lots of contexts, and then tried to
use it in a different context where it doesn't work.

The '=' in a declaration is not an assignment but rather is used
for initialization. Assignment and initialization are similar
in many ways but not in all ways.

For the declaration of 'op', what is being initialized is an
array. Initializers for arrays usually are written using a
brace-enclosed list of values, such as

char op[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };

For arrays of character type, C also allows two special forms

char op[8] = "foo";

or

char op[8] = { "foo" };

The declaration of op[8] in your program doesn't use any of those
three forms, so the compiler complains.

To get what you want, you could write a rather cumbersome array
initializer:

char op[8] = { istest ? 'e' : 'd', 'f' };

Alternatively, you could declare op[8] without an initializer and
subsequently use a string function such as strcpy() to provide
values to array elements (which in some cases will be only some
of the array elements, but presumably you don't care about that
as long as there is a terminating null). This method is similar
to the code in your followup posting.

For this particular usage, strncpy() may be a better choice than
strcpy(), as for example

strncpy( op, istest?"ef":"df", sizeof op );

because it will initialize all the elements of the array, and
also is guaranteed not to write beyond the end of the array,
which could happen if strcpy() were used (depending of course
on what string is provided for the second argument).

Mateusz Viste <mateusz@xyz.invalid> wrote:
> 2022-01-25 at 13:00 -0000, John Forkosh wrote:
>> Minimal working (or should I say non-working example)...
>>
>> #include <stdio.h>
>> int main () {
>> int istest=1;
>> char op[8] = (istest?"ef":"df");
>> /*char op[8] = "ef";*/
>> printf("op=%s\n",op); }
>>
>> for which cc emits the error...
>>
>> test.c: In function 'main':
>> test.c:4:16: error: invalid initializer
>> 4 | char op[8] = (istest?"ef":"df");
>> | ^
>>
>> But if I comment out that line and uncomment the one below it,
>> then it compiles and runs fine. I've used this construction
>> a million times without problems. But a-million-and-one seems
>> to somehow be a problem. What's wrong???
>
> I do not think that an array initializer can be a conditional
> expression.
>
> Are you sure that in your million previous times you were initializing
> an array, and not a pointer? ie. this should work as you expect:
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char *op = (istest?"ef":"df");
> printf("op=%s\n",op);
> }
>
> Mateusz

Thanks, Mateusz. Yeah, as you and Bart point out, my million previous
times must have been compliant with the standards. I'd of sworn I'd
done it exactly as originally illustrated, but I guess not.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> John Forkosh <forkosh@panix.com> writes:
>
>> Minimal working (or should I say non-working example)...
>>
>> #include <stdio.h>
>> int main () {
>> int istest=1;
>> char op[8] = (istest?"ef":"df");
>> /*char op[8] = "ef";*/
>> printf("op=%s\n",op); }
>>
>> for which cc emits the error...
>>
>> test.c: In function 'main':
>> test.c:4:16: error: invalid initializer
>> 4 | char op[8] = (istest?"ef":"df");
>> | ^
>>
>> But if I comment out that line and uncomment the one below it,
>> then it compiles and runs fine. I've used this construction
>> a million times without problems. But a-million-and-one seems
>> to somehow be a problem. What's wrong???
>
> What you've done is take a construct (the istest?"ef":"df"
> subexpression) that works in lots of contexts, and then tried to
> use it in a different context where it doesn't work.
>
> The '=' in a declaration is not an assignment but rather is used
> for initialization. Assignment and initialization are similar
> in many ways but not in all ways.
>
> For the declaration of 'op', what is being initialized is an
> array. Initializers for arrays usually are written using a
> brace-enclosed list of values, such as
>
> char op[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
>
> For arrays of character type, C also allows two special forms
>
> char op[8] = "foo";
> or
> char op[8] = { "foo" };
>
> The declaration of op[8] in your program doesn't use any of those
> three forms, so the compiler complains.
>
> To get what you want, you could write a rather cumbersome array
> initializer:
>
> char op[8] = { istest ? 'e' : 'd', 'f' };

Thanks, Tim. That's certainly ingenious. After reading Bart's
answer, I first tried thinking/trying various syntactic fixes
to get the compiler to do what I wanted. But nothing I tried
worked, and your solution, which indeed works, never crossed
my mind.

> Alternatively, you could declare op[8] without an initializer and
> subsequently use a string function such as strcpy() to provide
> values to array elements (which in some cases will be only some
> of the array elements, but presumably you don't care about that
> as long as there is a terminating null). This method is similar
> to the code in your followup posting.

Yeah, that's what I'm gonna do. No need to get fancy, or anything.
If I'd just realized my blunder, I'd just have done that to begin
with, and never posted any question. I only posted because the
problem completely baffled me. The strcpy() workaround was immediately
obvious.

> For this particular usage, strncpy() may be a better choice than
> strcpy(), as for example
>
> strncpy( op, istest?"ef":"df", sizeof op );
>
> because it will initialize all the elements of the array, and
> also is guaranteed not to write beyond the end of the array,
> which could happen if strcpy() were used (depending of course
> on what string is provided for the second argument).

Not any potential problem. The opcode syntax is fixed size,
and I've already allocated more than it'll ever need, precisely
for those "just in case" situations.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

On 1/25/22 08:00, John Forkosh wrote:
> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. ...

The line that was commented line works because of the following clause
from the standard:

"An array of character type may be initialized by a character string
literal or UTF–8 string literal, optionally enclosed in braces.
Successive bytes of the string literal (including the terminating null
character if there is room or if the array is of unknown size)
initialize the elements of the array." (6.7.9p14).

The line you actually used doesn't initialize the array with a string
literal, but with the result of a conditional expression. That
conditional expression has string literals as operands, but the
initializer is not, itself, a string literal.

"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." (6.3.2.1p4).

"ef" and "df" are expressions of array type, so the above conversion
applies. The exception for "a string literal used to initialize an
array" does NOT apply, because it's the conditional expression's value
that is being used to initialize the array, not the string literals.

Therefore, both the second and third operands of the conditional
expression are pointers to char, and therefore so is the result of that
expression. You cannot use a char* as an initializer for an array.

One alternative that would work is

const char* op = (istest ? "ef" : "df");

But I had to add the 'const' qualifier because it's undefined behavior
to write to those strings. If you need writable memory, another
alternative would be:

char ef_op[8] = "ef";
char df_op[8] = "df";
char *op = (istest ? ef_op : df_op);

But if do you need writable memory, I think the best way to do this
would be:

char op[8];
strcpy(op, istest ? "ef" : "df");

The other failed example that you provided in a later message fails for
exactly the same reason:

> char op[8] = (char *)"ef";

(char*)"ef" is a cast expression, not a string literal. "ef" is not
being used to initialize op, but as an operand of the cast operator. As
such, it get implicitly converted into a pointer to the first element of
the array, and then redundantly converted to a char*, something that
cannot be used to initialize an array.

> ... I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

I doubt that you've ever used precisely this construct before - all of
the relevant aspects of C have remained unchanged since K&R C. Anything
you actually did must have differed from this construct in some
important way.

John Forkosh <forkosh@panix.com> writes:
>char op[8] = (istest?"ef":"df");

Well, I find here:

|An array of character type may be initialized by a character
|string literal or UTF–8 string literal, optionally enclosed
|in braces.
....
|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.

. So, if I have not missed anything and this is the complete
list of possible ways to initialize an array of character type,
that would explain the error message!

What about "#include <string.h>" and then »char op[ 8 ];
strcpy( op, istest? "ef": "df" );«?

John Forkosh <forkosh@panix.com> writes:
> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

The "=" symbol can be used either in an assignment or in an declaration
with an initializer. They look similar, but they're different.

For example:

int n = 42; // an declaration with an initializer
n = 42; // an assignment

The "=" in the declaration must be followed by an *initializer*, which
can be either an expression or a sequence of one or more initializers
enclosed in { ... }. The "=" in the assignment must be followed by an
expression.

A declaration like

char op[8] = "ef";

is a special case. Arrays can be initialized, but they can't be
assigned, so this:

op = "ef";

is invalid. The special case is that you can use a string literal
as the initializer for an array object (of an appropriate type).
There is no such special case for more complicated expressions like
(istest?"ef":"df").

Somewhat similarly, but following from a different set of rules, this is
valid:

int a[] = { 10, 20, 30 };

but this is not:

int a[] = cond ? { 10, 20, 30 } : { 40, 50, 60 };

because { 10, 20, 30 } is an initializer but not an expression.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 1/25/2022 5:00 AM, John Forkosh wrote:
> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

Not sure about the intent of your question. Are you asking how it
contradicts rules of the language? Or are you asking why the rules of
the language are written that way?

The answer to the former is that each string literal ("ef" and "df") is
an array. Arrays in C are affected by so called "array type decay": they
turn into pointers, with the exception of several immediate contexts

1. Operand of unary `&`
2. Operand of `sizeof`
3. Operand of `_Alignof`
4. String literal initializer for a `char[]` array

This why your commented-out line compiles: it is excepted from the decay
by point 4 and handled in a very special way, described in the standard.

Your original declaration is not excepted by any of these rules. So,
your literals decay to pointers. And pointers cannot be used to
initialize arrays. End of story.

As for why the language standard is written that way... Well, that's
just the way it works in C.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
[...]
> The answer to the former is that each string literal ("ef" and "df")
> is an array. Arrays in C are affected by so called "array type decay":
> they turn into pointers, with the exception of several immediate
> contexts
>
> 1. Operand of unary `&`
> 2. Operand of `sizeof`
> 3. Operand of `_Alignof`
> 4. String literal initializer for a `char[]` array
[...]

The operand of _Alignof is not one of the exceptions.

It was incorrectly listed as one in the N1570 draft, but that was
corrected in the published 2011 ISO C standard.

_Alignof, unlike sizeof, can only take a parenthesized type name as an
operand, so it doesn't apply. (I don't know why _Alignof doesn't take
an expression operand.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 1/25/22 22:49, Andrey Tarasevich wrote:
> On 1/25/2022 5:00 AM, John Forkosh wrote:
>> Minimal working (or should I say non-working example)...
>>
>> #include <stdio.h>
>> int main () {
>> int istest=1;
>> char op[8] = (istest?"ef":"df");
>> /*char op[8] = "ef";*/
>> printf("op=%s\n",op); }
>>
>> for which cc emits the error...
>>
>> test.c: In function 'main':
>> test.c:4:16: error: invalid initializer
>> 4 | char op[8] = (istest?"ef":"df");
>> | ^
>>
>> But if I comment out that line and uncomment the one below it,
>> then it compiles and runs fine. I've used this construction
>> a million times without problems. But a-million-and-one seems
>> to somehow be a problem. What's wrong???
>
> Not sure about the intent of your question. Are you asking how it
> contradicts rules of the language? Or are you asking why the rules of
> the language are written that way?
>
> The answer to the former is that each string literal ("ef" and "df")
> is an array. Arrays in C are affected by so called "array type decay":
> they turn into pointers, with the exception of several immediate contexts
>
> 1. Operand of unary `&`
> 2. Operand of `sizeof`
> 3. Operand of `_Alignof`
> 4. String literal initializer for a `char[]` array
>
> This why your commented-out line compiles: it is excepted from the
> decay by point 4 and handled in a very special way, described in the
> standard.
>
> Your original declaration is not excepted by any of these rules. So,
> your literals decay to pointers. And pointers cannot be used to
> initialize arrays. End of story.
>
> As for why the language standard is written that way... Well, that's
> just the way it works in C.

Those rules are far better motivated than implied by that wording.

The implicit conversion of expressions with array type into pointers to
the first element of the array was intended to be a convenience feature.
Without that rule, since C doesn't allow passing arguments by reference,
&array[0] would have to be an excessively common construct.
The only exceptions to that rule are necessary - if they weren't
exceptions, there would be no good alternatives for achieving the same
result that they do achieve because they are exceptions.

In C, strings are not a data type, but rather a data format: an
null-terminated array of char. That string literals can be used to
initialize such an array was also a convenience feature. Without that
rule, we'd have to use:

char greeting[] = {'H', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r',
'l', 'd', '!', '\0'};

or

strcpy(greeting, "Hello, world!");

Unfortunately, these convenience features led to the widespread
confusion that "arrays are pointers". Less widespread is the other
misconception that is shown in this thread, that character arrays can be
initialized using a pointer to another array of the same type.

On 1/25/2022 8:37 PM, James Kuyper wrote:
>>
>> As for why the language standard is written that way... Well, that's
>> just the way it works in C.
>
> Those rules are far better motivated than implied by that wording.

I didn't intend to imply that. It is just a separate story, which I'm
not sure the OP wanted to hear.

> The implicit conversion of expressions with array type into pointers to
> the first element of the array was intended to be a convenience feature.
> Without that rule, since C doesn't allow passing arguments by reference,
> &array[0] would have to be an excessively common construct.
> The only exceptions to that rule are necessary - if they weren't
> exceptions, there would be no good alternatives for achieving the same
> result that they do achieve because they are exceptions.

Dennis Ritchie in "The Development of the C Language" mentions what
appears to be a fairly different rationale. The way arrays are
implemented in C is basically the "common denominator" of the following
two objectives:

1. Preserve as much as possible source-level backward compatibility with
B language, where arrays are actually implemented through physical pointers.

2. Make arrays act as "shallow" members of struct types. Keep struct
types trivial and memcpy-copyable even when they contain arrays.

Trying to marry the two, he adopted the idea of a "non-pointer yet
happily decaying" arrays. He preserved value-context behavior of B
arrays, but changed their object-context behavior.

--
Best regards,
Andrey Tarasevich

On 2022-01-25, John Forkosh <forkosh@panix.com> wrote:
> Minimal working (or should I say non-working example)...
>
> #include <stdio.h>
> int main () {
> int istest=1;
> char op[8] = (istest?"ef":"df");
> /*char op[8] = "ef";*/
> printf("op=%s\n",op); }
>
> for which cc emits the error...
>
> test.c: In function 'main':
> test.c:4:16: error: invalid initializer
> 4 | char op[8] = (istest?"ef":"df");
> | ^
>
> But if I comment out that line and uncomment the one below it,
> then it compiles and runs fine. I've used this construction
> a million times without problems. But a-million-and-one seems
> to somehow be a problem. What's wrong???

Initialization is not assignment, as others have answered.
An array of char may be initialized by a literal, and that
has special meaning.

Note that arrays cannot be assigned at all in C:

char a[5];
a = "abc"; // error

A solution which is semantically close to the apparent
intended meaning of what you're trying to do is this:

char op[8] = { istest ? 'e' : 'd', 'f' };

(This uses a non-constant expression for initializing an aggregate
member, which was not required to work in ISO C C90, but became standard
as of C99, at least for aggregates defined in automatic storage.)

By semantically close I mean that op is the the type that you seem to
want: a modifiable array of 8 characters, and that the goal of
initializing that array one way or the other based on the flag is
satisfied.

Whereas:

char *op = istest ? "ef" : "df";

is certainly succinct, op is not an array but a pointer.
Therefore sizeof (op) calculates sizeof (char *) which is
unrelated to how many characters there are in the underlyinga
array. It points to an array which is not of 8 chars but 3, and
that is not required to be modifiable; this is not well-defined
behavior, under this definition of op:

op[0] = 'g';

Another solution:

char op[8];
strcpy(op, istest ? "ef" : "df");

If istest can be a compile-time condition:

#define istest 1

#if istest
#define iftest_init(THEN, ELSE) THEN
#define iftest(THEN, ELSE) (THEN)
#else
#define iftest_init(THEN, ELSE) ELSE
#define iftest(THEN, ELSE) (ELSE)
#endif

char op[8] = iftest_init("ef", "df");

iftest() generates parentheses, which we want almost all the time,
except here; so we introduce iftest_init() which doesn't do that.

Defining "if" macros like this requires a bit of upfront verbiage,
but the resulting code can be preferrable to code like:

#if test
char op[8] = "ef";
#else
char op[8] = "df";
#endif

or even

char op[8] =
#if test
"ef"
#else
"df"
#endif
;

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 1/25/22 08:00, John Forkosh wrote:
>> Minimal working (or should I say non-working example)...
>>
>> #include <stdio.h>
>> int main () {
>> int istest=1;
>> char op[8] = (istest?"ef":"df");
>> /*char op[8] = "ef";*/
>> printf("op=%s\n",op); }
>>
>> for which cc emits the error...
>>
>> test.c: In function 'main':
>> test.c:4:16: error: invalid initializer
>> 4 | char op[8] = (istest?"ef":"df");
>> | ^
>>
>> But if I comment out that line and uncomment the one below it,
>> then it compiles and runs fine. ...
>
> The line that was commented line works because of the following clause
> from the standard:
>
> "An array of character type may be initialized by a character string
> literal or UTF???8 string literal, optionally enclosed in braces.
> Successive bytes of the string literal (including the terminating null
> character if there is room or if the array is of unknown size)
> initialize the elements of the array." (6.7.9p14).
>
> The line you actually used doesn't initialize the array with a string
> literal, but with the result of a conditional expression. That
> conditional expression has string literals as operands, but the
> initializer is not, itself, a string literal.
>
> "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." (6.3.2.1p4).
>
> "ef" and "df" are expressions of array type, so the above conversion
> applies. The exception for "a string literal used to initialize an
> array" does NOT apply, because it's the conditional expression's value
> that is being used to initialize the array, not the string literals.
>
> Therefore, both the second and third operands of the conditional
> expression are pointers to char, and therefore so is the result of that
> expression. You cannot use a char* as an initializer for an array.
>
> One alternative that would work is
>
> const char* op = (istest ? "ef" : "df");
>
> But I had to add the 'const' qualifier because it's undefined behavior
> to write to those strings. If you need writable memory, another
> alternative would be:
>
> char ef_op[8] = "ef";
> char df_op[8] = "df";
> char *op = (istest ? ef_op : df_op);
>
> But if do you need writable memory, I think the best way to do this
> would be:
>
> char op[8];
> strcpy(op, istest ? "ef" : "df");

Thanks for the several working alternatives. As mentioned earlier,
strcpy()'s the one I already went with. But char ef[8]="ef",df[8]="df";
char *op=(istest?ef:df); is yet another one I hadn't thought of.

> The other failed example that you provided in a later message fails for
> exactly the same reason:
>
>> char op[8] = (char *)"ef";
>
> (char*)"ef" is a cast expression, not a string literal. "ef" is not
> being used to initialize op, but as an operand of the cast operator. As
> such, it get implicitly converted into a pointer to the first element of
> the array, and then redundantly converted to a char*, something that
> cannot be used to initialize an array.

Sure. As mentioned in followup to Bart, I only tried that to double-check
Bart's (and your above) explanation. I was already expecting it to fail
for exactly Bart's (and your) reason, which I hadn't been previously
aware of. And just wanted to explicitly see it for myself. Before this
thread, I'd have expected it to work (but had never written it that way,
`cause "why bother?").

>> ... I've used this construction
>> a million times without problems. But a-million-and-one seems
>> to somehow be a problem. What's wrong???
>
> I doubt that you've ever used precisely this construct before - all of
> the relevant aspects of C have remained unchanged since K&R C. Anything
> you actually did must have differed from this construct in some
> important way.

As previously noted, agreed. But I'd have (inaccurately) sworn I had.
And I tried grep ? *.c|grep : to find some cases, but the closest I
came was stuff like char *infile = (argc>1?argv[1]:"testfile.txt");
which legitimately assigns to *ptrs, as everybody mentioned.
Thanks again, James, and "everybody".
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> The "=" symbol can be used either in an assignment or in an declaration
> with an initializer. They look similar, but they're different. For example:
> int n = 42; // an declaration with an initializer
> n = 42; // an assignment
> The "=" in the declaration must be followed by an *initializer*, which
> can be either an expression or a sequence of one or more initializers
> enclosed in { ... }. The "=" in the assignment must be followed by an
> expression. A declaration like
> char op[8] = "ef";
> is a special case. Arrays can be initialized, but they can't be
> assigned, so this:
> op = "ef";
> is invalid. The special case is that you can use a string literal
> as the initializer for an array object (of an appropriate type).
> There is no such special case for more complicated expressions like
> (istest?"ef":"df").
>
> Somewhat similarly, but following from a different set of rules, this is
> valid:
> int a[] = { 10, 20, 30 };
> but this is not:
> int a[] = cond ? { 10, 20, 30 } : { 40, 50, 60 };
> because { 10, 20, 30 } is an initializer but not an expression.

Interesting example. And, yeah, I'd never think of trying to write
(cond?{10,20,30}:{40,50,60}) in any context. Just doesn't look right.
Actually, though I'm apparently prone to be wrong, I'd think there
isn't any context where that would compile without error.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
> Not sure about the intent of your question. Are you asking how it
> contradicts rules of the language? Or are you asking why the rules of
> the language are written that way?

Neither... just asking "if it contradicts". I'd been sure it was okay,
and spent like 5 minutes looking for a missing ; or something to
explain why it was throwing the error. Only when I gave up and
separately wrote that 5-line "minimal (non-)working example" did
I realize it was itself an error.

> The answer to the former is that each string literal ("ef" and "df") is
> an array. Arrays in C are affected by so called "array type decay": they
> turn into pointers, with the exception of several immediate contexts
>
> 1. Operand of unary `&`
> 2. Operand of `sizeof`
> 3. Operand of `_Alignof`
> 4. String literal initializer for a `char[]` array
>
> This why your commented-out line compiles: it is excepted from the decay
> by point 4 and handled in a very special way, described in the standard.
>
> Your original declaration is not excepted by any of these rules. So,
> your literals decay to pointers. And pointers cannot be used to
> initialize arrays. End of story.
>
> As for why the language standard is written that way... Well, that's
> just the way it works in C.

Yeah, "why" stopped bothering me long ago. There are various grammatical
rules that don't quite jibe with my personal sensibilities, but I've
got more pressing issues than arguing about them. Just need to know what
they are, which in this case I didn't.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Kaz Kylheku <480-992-1380@kylheku.com> wrote:
> Initialization is not assignment, as others have answered.
> An array of char may be initialized by a literal, and that
> has special meaning. Note that arrays cannot be assigned
> at all in C:
> char a[5];
> a = "abc"; // error
> A solution which is semantically close to the apparent
> intended meaning of what you're trying to do is this:
> char op[8] = { istest ? 'e' : 'd', 'f' };

Yeah, Tim already suggested this alternative.
Way too ugly. Maybe okay as an isolated line,
but in 500+ lines you don't want to have to pause
for 5+ secs figuring out the intent of one little line.

> (This uses a non-constant expression for initializing an aggregate
> member, which was not required to work in ISO C C90, but became standard
> as of C99, at least for aggregates defined in automatic storage.)
>
> By semantically close I mean that op is the the type that you seem to
> want: a modifiable array of 8 characters,

Yes, exactly. Glad you noticed, and I >>should<< have (but neglected
to) mentioned that earlier myself. char op[8]="ef"; where the 'f' means
read from a file, whereas after that initial read, subsequent passes
typically change op[1]='b' to read from an internal buffer.
So, as you point out below, char *op="ef"; compiles okay but won't
work... which is another kind of error I also discovered the hard way,
a long, long time ago (but in a relatively nearby galaxy).

> and that the goal of
> initializing that array one way or the other based on the flag is
> satisfied. Whereas:
> char *op = istest ? "ef" : "df";
> is certainly succinct, op is not an array but a pointer.
> Therefore sizeof (op) calculates sizeof (char *) which is
> unrelated to how many characters there are in the underlyinga
> array. It points to an array which is not of 8 chars but 3, and
> that is not required to be modifiable; this is not well-defined
> behavior, under this definition of op:
> op[0] = 'g';

You seem to have forgotten to add the subsequent "won't work" phrase,
though that's obviously what you meant. And thanks for mentioning it,
which prompted and reminded me to add my immediately preceding remarks.
And sorry to everybody else who suggested that char *op...; solution
for not mentioning it sooner.

> Another solution:
> char op[8];
> strcpy(op, istest ? "ef" : "df");
Yup, that's what I've done.

> If istest can be a compile-time condition:
> #define istest 1
> #if istest
> #define iftest_init(THEN, ELSE) THEN
> #define iftest(THEN, ELSE) (THEN)
> #else
> #define iftest_init(THEN, ELSE) ELSE
> #define iftest(THEN, ELSE) (ELSE)
> #endif
> char op[8] = iftest_init("ef", "df");
> iftest() generates parentheses, which we want almost all the time,
> except here; so we introduce iftest_init() which doesn't do that.
> Defining "if" macros like this requires a bit of upfront verbiage,

You think??? Very cute, and maybe if I were initializing tons
of stuff this way it'd be useful.

> but the resulting code can be preferrable to code like:
> #if test
> char op[8] = "ef";
> #else
> char op[8] = "df";
> #endif
> or even
> char op[8] =
> #if test
> "ef"
> #else
> "df"
> #endif
> ;

Actually, that second way is how I typically initialize stuff like
static int msglevel =
#if defined(MSGLEVEL) /* if cc -DMSGLEVEL=nn */
MSGLEVEL;
#else
3;
#endif
(you recall the parameters on the jcl //job card?:)
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> John Forkosh <forkosh@panix.com> writes:
>>char op[8] = (istest?"ef":"df");
>
> Well, I find here:
>
> |An array of character type may be initialized by a character
> |string literal or UTF???8 string literal, optionally enclosed
> |in braces.
> ...
> |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.
>
> . So, if I have not missed anything and this is the complete
> list of possible ways to initialize an array of character type,
> that would explain the error message!
>
> What about "#include <string.h>" and then ??char op[ 8 ];
> strcpy( op, istest? "ef": "df" );???

Thanks, yeah, that's what I did to fix it, even before
posting here and realizing why the initialization was failing.
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )