[C] Indovinello trovato in giro

[cdimauro]

Originariamente inviato da The_ouroboros

cmq un altra curiosità del linguaggio C è

#include <stdio.h>
#include <stdlib.h>

int main()
{
  int a = 0;
  printf("a =  %d \n", a);
  if(a+1) {}
  printf("a+1 in if %d \n", a);
  if(a++){}
  printf("a++ in if %d \n", a);
  return 0;
}

che non è coerente su tutte le piattaforme.
Provate e ditemi

Questo è sempre corretto.

Originariamente inviato da The_ouroboros

era preso da un contesto tipo

a=0; b = (a++,a+1,a+2);

e vedere cosa è b.
Su sistemi non x86/x64 non è detto che l'ordine sia sx->dx.
Quello era un piccolo particolare

Questo, invece, dovrebbe dipendere dall'ordine di valutazione delle espressioni, che non è garantito in C.

[The_ouroboros]

Originariamente inviato da cdimauro

Questo è sempre corretto.

Questo, invece, dovrebbe dipendere dall'ordine di valutazione delle espressioni, che non è garantito in C.

secondo il K&R in ita che ho io dovrebbe essere sx->dx. Però in effetti non dice SEMPRE

P.S: se queste cose sono banali o tediose, ditelo

[Vincenzo1968]

Il risultato è corretto.

Se vuoi che stampi 1 nel primo caso devi modificare il codice da così:

#include <stdio.h>
#include <stdlib.h>

int main()
{
  int a = 0;
  printf("a =  %d \n", a);
  if(a+1) {}
  printf("a+1 in if %d \n", a);
  if(a++){}
  printf("a++ in if %d \n", a);
  return 0;
}

a così:

#include <stdio.h>
#include <stdlib.h>

int main()
{
	int a = 0;
	printf("a =  %d \n", a);
	
	if( a = a+1 ) {}
	printf("a+1 in if %d \n", a);
	
	if(a++){}
	printf("a++ in if %d \n", a);
}

E, ovviamente, la seconda printf stamperà 2.

[cdimauro]

Originariamente inviato da The_ouroboros

secondo il K&R in ita che ho io dovrebbe essere sx->dx. Però in effetti non dice SEMPRE

Già. Il compilatore ha la libertà di decidere come valutare le espressioni.

Dovrebbe essere scritto, se non ricordo male, che si vuole essere sicuri di voler preservare l'esatto ordine di valutazione, bisogna ricorrere a delle assegnazioni con variabili di appoggio; ovviamente fuori dalle espressioni (come istruzioni a se stanti).

Comunque il K&R non lo leggo da un pezzo, per cui prendilo con le pinze.

P.S: se queste cose sono banali o tediose, ditelo

Ma no, sono interessanti. Altrimenti il thread sarebbe andato deserto.

[Vincenzo1968]

[banryu79]

Prova a confrontarla con questa:

a=0; b = (++a,a+1,a+2);

(Sì, lo so che non dovrebbe cambiare una mazza...)

[The_ouroboros]

Appena sono a casa provo.. Sono appena uscito dall'ufficio e mi trovo in treno..

Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[Vincenzo1968]

int main()
{
	int a = 0;
	int b = 0;
	
	printf("a =  %d \n", a);
	
	a=0; b = (++a,a+1,a+2);
	if( a ) {}
	printf("a+1 in if %d \n", a);
	printf("b = %d \n", b);
	
	if(a++){}
	printf("a++ in if %d \n", a);
}

risultato:

a =  0 
a+1 in if 1 
b = 3 
a++ in if 2

[Vincenzo1968]

Se volete che stampi b = 4 dovete fare così:

	b = ( ++a, a = a + 1, a = a + 2 );

[The_ouroboros]

Interessante.. Grazie x aver proseguito la traccia...

Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[Gigibian]

Originariamente inviato da The_ouroboros

dioendente dall'endianness mi sembra

Originariamente inviato da cdimauro

Purtroppo sì, perché in quella printf il compilatore esegue il push di tutto il valore, che è un intero (1160290625); non sa che in quel posto la funzione si aspetta un char (in realtà in questo caso sì, perché la stringa è costante; ma soprassediamo considerando il caso più generale).

Poi la routine di parsing, facendo la scansione dello stack, in base al template che gli hai passato, carica il valore che gli serve, in base al tipo specificato nel template. E lì possono succedere anche dei disastri.

In realtà il risultato non è garantito nemmeno su un sistema little-endian, perché un compilatore potrebbe avere i char a 16 bit, e quindi caricare 2 byte anziché uno soltanto...

Supponendo di avere una macchina dove 1 byte=8 bit, il risultato non dovrebbe essere indipendente dall ' endianess ? Non viene cmq stampato l MSB sia che sia a SX che a DX ?

[Gigibian]

Originariamente inviato da cdimauro

Questo è sempre corretto.

Questo, invece, dovrebbe dipendere dall'ordine di valutazione delle espressioni, che non è garantito in C.

K&R pagina 59: l operatore "comma" valuta da sinistra a destra.
Quindi dovrebbe essere sempre corretto....

[Gigibian]

Originariamente inviato da cdimauro

Già. Il compilatore ha la libertà di decidere come valutare le espressioni.

Dovrebbe essere scritto, se non ricordo male, che si vuole essere sicuri di voler preservare l'esatto ordine di valutazione, bisogna ricorrere a delle assegnazioni con variabili di appoggio; ovviamente fuori dalle espressioni (come istruzioni a se stanti).

Comunque il K&R non lo leggo da un pezzo, per cui prendilo con le pinze.

Ma no, sono interessanti. Altrimenti il thread sarebbe andato deserto.

Non avevo notato che qualcuno l avesse già evidenziato :P.
No cmq l operatore comma, come tutti gli operatori, ha l ordine di valutazione garantito.
Sono alcune espressioni che non è definito come.vengono valutate.
Ad esempio non sai quali parametri.vengono valutati prima in una definizione di funzione:
Func(a,b,c)

[WarDuck]

Strano, mi sarei aspettato di vedere solo la prima print.

a++ non dovrebbe essere valutato 0 in quel caso (ovvero il valore della variabile corrente)?

Forse fa prima l'incremento e poi valuta l'if sul registro in questione?

Comunque questo è un motivo per cui cerco sempre di esplicitare il più possibile la condizione, evitando cose di quel tipo che possono creare grossi problemi in chi legge .

[cdimauro]

Idem.

Originariamente inviato da Gigibian

Supponendo di avere una macchina dove 1 byte=8 bit, il risultato non dovrebbe essere indipendente dall ' endianess ? Non viene cmq stampato l MSB sia che sia a SX che a DX ?

No, perché, supponendo che l'intero generato dall'espressione sia a 32 bit, una macchina little-ending esegue il push dei 4 byte sullo stack in ordine inverso rispetto a una big-endian.
Nel momento in cui si referenzia un singolo byte, con una macchina little-endian questo coincide col byte basso dell'intero a 32 bit memorizzato nello stack, mentre per una big-endian corrisponderà a quello alto (da cui il nome, per entrambi).

Originariamente inviato da Gigibian

K&R pagina 59: l operatore "comma" valuta da sinistra a destra.
Quindi dovrebbe essere sempre corretto....

Sì, ho visto che per quest'operatore è garantito.

Originariamente inviato da Gigibian

Non avevo notato che qualcuno l avesse già evidenziato :P.
No cmq l operatore comma, come tutti gli operatori, ha l ordine di valutazione garantito.

No, sono pochi gli operatori per i quali il compilatore garantisce l'ordine di valutazione corretto. Dallo standard ANSI:

Except as indicated by the syntax /27/ or otherwise specified later
(for the function-call operator () , && , || , ?: , and comma
operators), the order of evaluation of subexpressions and the order in
which side effects take place are both unspecified.

Sono alcune espressioni che non è definito come.vengono valutate.
Ad esempio non sai quali parametri.vengono valutati prima in una definizione di funzione:
Func(a,b,c)

Sì, è scritto sopra.

[Gigibian]

Originariamente inviato da cdimauro

Idem.

No, perché, supponendo che l'intero generato dall'espressione sia a 32 bit, una macchina little-ending esegue il push dei 4 byte sullo stack in ordine inverso rispetto a una big-endian.
Nel momento in cui si referenzia un singolo byte, con una macchina little-endian questo coincide col byte basso dell'intero a 32 bit memorizzato nello stack, mentre per una big-endian corrisponderà a quello alto (da cui il nome, per entrambi).

Sì, ho visto che per quest'operatore è garantito.

No, sono pochi gli operatori per i quali il compilatore garantisce l'ordine di valutazione corretto. Dallo standard ANSI:

Except as indicated by the syntax /27/ or otherwise specified later
(for the function-call operator () , && , || , ?: , and comma
operators), the order of evaluation of subexpressions and the order in
which side effects take place are both unspecified.

Sì, è scritto sopra.

Innanzitutto grazie mille della risposta Cesare

tutto chiaro, per quanto riguarda altri gli altri operatori stavo confondendo l' ordine di valutazione con l'associativita che é definita ovviamente x tutti gli operatori