[C] Indovinello trovato in giro

[The_ouroboros]

Ciao a tutti,
girava stamani in ufficio.

#include<stdio.h>
#define s 65*65*65*65*65
void main()
{
printf("%c",s);
}

Cosa stampa e perchè?

Buon lunedì a tutti.

[cdimauro]

>>> print chr(65*65*65*65*65 & 0xff)
A

Ovviamente perché l'intero risultante viene troncato alla dimensione del char, che dovrebbe (usualmente, ma non è detto) essere di un byte.

[The_ouroboros]

Originariamente inviato da cdimauro

>>> print chr(65*65*65*65*65 & 0xff)
A

Ovviamente perché l'intero risultante viene troncato alla dimensione del char, che dovrebbe (usualmente, ma non è detto) essere di un byte.

dioendente dall'endianness mi sembra

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

[The_ouroboros]

interessanti osservazioni.
Mi piaciono queste sottigliezze e curiosità.
Spero di non essere andato troppo oltre ma dati gli ultimi giorni di discussioni su lavoro/uni volevo tornare alla programmazione

[sottovento]

non stampa ovviamente nulla

[The_ouroboros]

Originariamente inviato da sottovento

non stampa ovviamente nulla

Su gcc 4.7.2 , debian x64, mi stampa A

[The_ouroboros]

anche Clang 3.1 su FreeBSD 9.1 x86_64 mi stampa A

[sottovento]

Originariamente inviato da The_ouroboros

anche Clang 3.1 su FreeBSD 9.1 x86_64 mi stampa A

Manca ancora qualche sistema da testare
Che ne so.... un System V collegato ad un VT52

[The_ouroboros]

Io quelli ho.

Inviato dal mio HUAWEI U8825-1 con Tapatalk 2

[banryu79]

Originariamente inviato da sottovento

Manca ancora qualche sistema da testare
Che ne so.... un System V collegato ad un VT52

[sottovento]

Originariamente inviato da banryu79

Supponi di avere un impianto che ti e' costato milioni di euri. Lo cambi perche' non fa il flush alla print()?

Cmq ci sono sistemi anche piu' recenti che si comportano allo stesso modo...

[banryu79]

Originariamente inviato da sottovento

Supponi di avere un impianto che ti e' costato milioni di euri. Lo cambi perche' non fa il flush alla print()?

Ovviamente no, però questo non cambia il fatto che...
Esticazzi, se permettete

[sottovento]

Originariamente inviato da banryu79

Ovviamente no, però questo non cambia il fatto che...
Esticazzi, se permettete

Si, permettiamo.
cmq il risultato potrebbe essere uguale anche su una macchina big endian. O anche no

[cdimauro]

No, dovrebbe essere 'E'. Sempre nell'ipotesi che venga prelevato un byte per il char.

[The_ouroboros]

Originariamente inviato da cdimauro

No, dovrebbe essere 'E'. Sempre nell'ipotesi che venga prelevato un byte per il char.

si?

[sottovento]

Originariamente inviato da cdimauro

No, dovrebbe essere 'E'. Sempre nell'ipotesi che venga prelevato un byte per il char.

Se il compilatore in questione conosce il prototipo della funzione (e supporta, ovviamente, i prototipi), puo' effettuare il cast a char PRIMA di fare il push nello stack. Il cast a char preleva sempre il byte meno significativo, indipendentemente dall'architettura big/little endian, cosi' farebbe il push nello stack della 'A'.

Quanto affermi e' chiaramente vero su compilatori K&R (passami la definizione) poiche' non conoscono nulla della funzione che vai a chiamare e non hanno alternativa a fare il push dei parametri loro passati. Me l'ha detto il mio commercialista

[cdimauro]

Originariamente inviato da The_ouroboros

si?

Il risultato della moltiplicazione è 0x4528a141. Se prendi il byte più significativo, è 0x45, che in ASCII corrisponde alla E.

Originariamente inviato da sottovento

Se il compilatore in questione conosce il prototipo della funzione (e supporta, ovviamente, i prototipi), puo' effettuare il cast a char PRIMA di fare il push nello stack. Il cast a char preleva sempre il byte meno significativo, indipendentemente dall'architettura big/little endian, cosi' farebbe il push nello stack della 'A'.

Quanto affermi e' chiaramente vero su compilatori K&R (passami la definizione) poiche' non conoscono nulla della funzione che vai a chiamare e non hanno alternativa a fare il push dei parametri loro passati. Me l'ha detto il mio commercialista

Francamente non ricordo questi dettagli, ma mi ero messo nelle condizioni generali.

[The_ouroboros]

lucas@lapdog:~$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
(65*65*65*65*65)%256
65

[cdimauro]

Così hai estratto il byte basso.

P.S. bc cos'è?