Re: 80386 C compiler

On Tue, 26 Nov 2024 17:59:08 -0000 (UTC), Kaz Kylheku  wrote:

On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:

On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku  wrote:
>

void fn(int a)
{
  int x[3] = { foo(), bar(), a }; /* not in C90 */

>
is in the above foo() called before bar()?

>
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
but C99 (which I happen to have open in a PDF reader tab) stated that
"The order in which any side effects occur among the initialization list
expressions is unspecified.".  This implies that there is no sequence
point between any two initializing expressions, which means we don't
know whose expression's function call takes place first.
>
In any case, a C90 compiler with the above support as an extension to
C90 can specify rigid sequencing behavior.
>

void fn(int a)
 {
   int x[3];
   x[0]=foo(); x[1]=bar(); x[2]=a;
>
this would be ok with every C compiler

>
One problem is, if you're doing this because your compiler is C90, you
also have to do something about all declarations which follow the int
x[3], since they cannot occur after a statement.  You can add another
level of block nesting for them, or whatever.

 int fn(int a)
{ int x[3];
  int b=9;
   x[0]=foo(); x[1]=bar(); x[2]=a;
   return x[0]==0||a==b;
}

i don't see onother level of block nesting

Initialization is preferable to leaving an object uninitialized and
assigning. There is a scope where the name is visible, but the object
is not initialized, inviting code to be inserted there which tries
to use it.
>
If I needed foo to be called before bar, I would still rather do
the following than assignment:
>
 int f = foo();
 int b = bar();
 int x[3] = { f, b, a };

ok