Newsgroup: it.comp.lang.c
Titolo: (unsigned long)(short)-1

Salve,
scusate il soggetto un po' insolito, ma era per chiarire subito di cosa 
sto parlando: secondo voi o, meglio, secondo lo standard, quale dovrebbe 
essere, assumendo che long sia grande 32 bit e short 16 bit, il 
risultato di tale espressione:
     (unsigned long)(short)-1;
O, in forma più esplicita (ovvero il caso da cui ho preso spunto per 
scrivere questo messaggio), a cosa dovrebbe essere uguale 'b':
     short         a = -1;
     unsigned long b = a;
Vi dico cosa dice gcc: dice che b = 4294967295. O meglio, il codice 
assembly emesso mostra proprio '-1', ma so bene che -1 o 4294967295 sono 
perfettamente equivalenti, in questo caso.
Ma il punto è: ha fatto bene gcc ad estendere il segno a 32 bit, di una 
variabile con segno di 16 bit, anche se la variabile finale è _senza_ segno?
Voglio dire, avessimo parlato di (long)(short)-1, non avrei da eccepire, 
ma visto che stiamo parlando di (UNSIGNED long)(short)-1, il numero 
risultante non dovrebbe essere 65535, oppure la regola è che 
l'estensione del segno avviene sempre e comunque, lasciando alle 
operazioni successive il compito di interpretare come d'uopo la 
"signedness" del valore risultante?
Saluti,
Fabio

 "signedness" del valore risultante?
Non e' che quanto ha scritto mi risulti molto chiaro, provo a dare una
risposta secondo quanto ho capito.
Il cast e' una operazione con ordine di valutazione da sinistra a
destra,
pertanto
(UNSIGNED long)(short)-1
viene interpretata come
(cast2)expr
con expr che vale (cast1)var
Pertanto viene fatto prima il cast di -1 a short e successivamente
al risultato di questa operazione viene applicato il cast a long.
il fatto che sia signed o unsigned dal punto di vista dell'occupazione
di memoria e' la stessa cosa, il risultato di tutta l'operazione e'
qualcosa che ha la dimensione di un long.
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 qualcosa che ha la dimensione di un long.
...anche 65536 ha la dimensione di una long, se occupa una long. Voglio 
dire, (unsigned long)(short)1 sara uguale ad 1, il quale occupera 
l'intera long.
Qui non si discute dell'occupazione di memoria, si discute 
dell'estensione del segno. Forse passando all'esadecimale le cose 
saranno piů chiare.
Sempre assumendo che short č grande 16 bit, e long 32 bit:
     (short)-1 = 0xFFFF
Ora, passando a 32 bit, _con_ estensione del segno, si ha:
     0xFFFFFFFF
Mentre _senza_ estensione del segno, si avrebbe:
     0x0000FFFF
Ora la mia domanda č: perché gcc estende il segno, nel caso del cast ad 
unsigned long? Ripeto, non avrei nulla da ecepire se stessimo parlando 
di "long", ma siccome stiamo parlando di una "unsigned long", e siccome 
gcc estende lo stesso il segno, mi viene da pensare che lo standard dica 
che ogni qual volta si passa da un tipo ad uno piů grande il segno viene 
_sempre_ esteso. E' questa a regola?
Fabio

 l'intera long.
Si, ma 65536 non e' il complemento a due di -1 se il numero e'
rappresentato con 32 bit.


 rappresentato con 32 bit.
Ed č questo il punto (anche se lě dovrebbe essere 65535)! Il compilatore 
ha esteso il segno. La domanda č: perché?
Fabio

 variabile con segno di 16 bit, anche se la variabile finale è _senza_ segno?
Non ha esteso il segno ;) O meglio, il risultato sembra quello, ma
l'operazione compiuta e` un'altra:
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
  other than _Bool, if the value can be represented by the new type, it is
  unchanged. 
2 Otherwise, if the new type is unsigned, the value is converted by
  repeatedly adding or subtracting one more than the maximum value that
  can be represented in the new type until the value is in the range of
  the new type.
L'operazione compiuta e` -1 + ULONG_MAX + 1, dove ULONG_MAX con le
ipotesi di cui sopra vale 4294967295. L'estensione di segno e` prevista
solo per tipi signed, ma la procedura qua` sopra e` studiata in modo da
dare lo stesso risultato sulle piattaforme che operano con numeri in
complemento a 2 (questioni di performance).
Luca
-- 
Home: 
http://kronoz.cjb.net
Il piu` bel momento dell'amore e` quando ci si illude che duri per 
sempre; il piu` brutto, quando ci si accorge che dura da troppo.