segno negativo non troncato con unsigned -C

[nero.23]

unsigned int x=-8;
printf("%d",x);

x, ￜ negativo (-8) e mi aspettavo che mi stampasse 8 con unsigned.

Perchￜ non mi tronca il segno meno?

grazie

nero23

[neonano]

Addì lunedì 19 novembre 2012 13:40 nero.23 scrisse:

> unsigned int x=-8;

ERRORE! (o meglio warning) x è unsigned, otterrai dei risultati
imprevedibili.




Addì lunedì 19 novembre 2012 13:40 nero.23 scrisse:

> printf("%d",x);
>
> x, è negativo (-8) e mi aspettavo che mi stampasse 8 con unsigned.
>
> Perchè non mi tronca il segno meno?

Perché hai detto di stampare un valore intero con segno.

[Lorenzo Beretta]

On 19/11/2012 14:01, neonano wrote:
> Addì lunedì 19 novembre 2012 13:40 nero.23 scrisse:
>
>> unsigned int x=-8;
>
> ERRORE! (o meglio warning) x è unsigned, otterrai dei risultati
> imprevedibili.
>

Correggetemi se sbaglio, ma giurerei che con gli *unsigned* non è
imprevedibile -- con i signed invece sono sicuro di sì.

[fma...@gmail.com]

On Monday, November 19, 2012 3:50:57 PM UTC+1, Lorenzo Beretta wrote:
> On 19/11/2012 14:01, neonano wrote:
> > Addì lunedì 19 novembre 2012 13:40 nero.23 scrisse:
> >> unsigned int x=-8;
>
> > ERRORE! (o meglio warning) x è unsigned, otterrai dei risultati
> > imprevedibili.
>
> Correggetemi se sbaglio, ma giurerei che con gli *unsigned* non è
> imprevedibile -- con i signed invece sono sicuro di sì.
>

Il problema è appunto che quel "-8" è un int, e lo stai assegnando ad un
unsigned! ;)
Ciao!

[enoquick]

In un linguaggio di programmazione di alto livello un assegnamento di
questo tipo sarebbe un errore o warning a tempo di compilazione e a
runtime un risultato imprevedibile in quanto l' assegnamento è fuori dal
dominio del problema.
In C ansi questo caso specifico non è cosi
Lo standard dice chiaramente questo:

When a signed integer is converted to an unsigned integer of equal or
greater size, and the signed integer value is nonnegative, its value is
unchanged. If the signed integer value is negative, then:

If the unsigned integer type is larger, the signed integer is first
promoted to the signed integer that corresponds to the unsigned integer;
then the value is converted to unsigned by adding to it one greater than
the largest number that can be represented in the unsigned integer type.

If the unsigned integer type is equal or smaller than the signed
integer type, then the value is converted to unsigned by adding to it
one greater than the largest number that can be represented in the
unsigned integer type.

[neonano]

Addì lunedì 19 novembre 2012 15:50 Lorenzo Beretta scrisse:

> Correggetemi se sbaglio, ma giurerei che con gli unsigned non è

> imprevedibile -- con i signed invece sono sicuro di sì.

"Imprevedibile" non vuol dire "non definito". Gli standard definiscono
per filo e per segno quali valori puoi ottenere dalla conversione, quale
valore otterrai dipende da molti fattori casuali.

Vedi risposta a enoquick

[neonano]

Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:

> In un linguaggio di programmazione di alto livello un assegnamento di
> questo tipo sarebbe un errore o warning a tempo di compilazione e a

> runtime ...

Distinzione irrilevante e cervellotica.


Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:

> ... un risultato imprevedibile in quanto l' assegnamento è fuori dal
> dominio del problema.
> ...

Stupidate. Molto più semplicemente in questo contesto "risultato
imprevedibile vuol dire: risultato che dipende dalla macchina, dal
compilatore e dalle opzioni. In realtà gli standard del linguaggio
hanno delle regole per trattare questi casi per cui i risultati
possibili sono ben definiti ma a priori tu non sai quale di questo
otterrai. Del resto tu stesso fai notare:


Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:

> In C ansi questo caso specifico non è cosi
> Lo standard dice chiaramente questo:

> ...

Cioè lo standard ha delle regole precise per la conversione di tipi,
però tu non puoi sapere se hai interi a sedici bit, a trentadue bit
o sarcazzo per cui non sai se -8 sia uguale a 0XF8, 0XFFF8,
0XFFFFFFF8 o sarcazzo.

[fma...@gmail.com]

On Monday, November 19, 2012 8:19:01 PM UTC+1, neonano wrote:
> Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:
> > > In un linguaggio di programmazione di alto livello un assegnamento di
> > questo tipo sarebbe un errore o warning a tempo di compilazione e a
> > runtime ...
>
> Distinzione irrilevante e cervellotica.
>

Forse, però sottolineava il perché l'OP non può aspettarsi certi risultati.

> Cioè lo standard ha delle regole precise per la conversione di tipi,
> però tu non puoi sapere se hai interi a sedici bit, a trentadue bit
> o sarcazzo per cui non sai se -8 sia uguale a 0XF8, 0XFFF8,
> 0XFFFFFFF8 o sarcazzo.

Giusto, fino ad un certo punto.
Proprio per i passi citati, se provi a convertire un int32_t ad un uint32_t
sai cosa succederà (parlando di C99, ovviamente)
In ogni caso concordo con il concetto di fondo: se ti serve un unsigned usi un
unsigned, altrimenti no, pena: ogni conversione va fatta pensando a quello che
potrebbe succedere nel peggiore dei casi.
Ciao!

[enoquick]

Il 19/11/2012 13:19, neonano ha scritto:
> Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:
>
>> In un linguaggio di programmazione di alto livello un assegnamento di
>> questo tipo sarebbe un errore o warning a tempo di compilazione e a
>> runtime ...
>
> Distinzione irrilevante e cervellotica.
>

Per tè che che forse non conosci altri linguaggi
In Ada ad esempio per la seguente dichiarazione

u : positive := -1;

il compilatore segnala:

warning: "Constraint_Error" will be raised at run time

>
> Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:
>
>> ... un risultato imprevedibile in quanto l' assegnamento è fuori dal
>> dominio del problema.
>> ...
>
> Stupidate. Molto più semplicemente in questo contesto "risultato
> imprevedibile vuol dire: risultato che dipende dalla macchina, dal
> compilatore e dalle opzioni.

Anche ma non è detto

In realtà gli standard del linguaggio
> hanno delle regole per trattare questi casi per cui i risultati
> possibili sono ben definiti ma a priori tu non sai quale di questo
> otterrai. Del resto tu stesso fai notare:
>
>
> Addì lunedì 19 novembre 2012 16:15 enoquick scrisse:
>
>> In C ansi questo caso specifico non è cosi
>> Lo standard dice chiaramente questo:
>> ...
>
> Cioè lo standard ha delle regole precise per la conversione di tipi,
> però tu non puoi sapere se hai interi a sedici bit, a trentadue bit
> o sarcazzo per cui non sai se -8 sia uguale a 0XF8, 0XFFF8,
> 0XFFFFFFF8 o sarcazzo.
>

Lo standard non parla, giustamente, di numero di bit

Ma dice quale deve essere il comportamento in caso di troncamento o no
Infatti aggiunge anche questo:

[enoquick]

Il 19/11/2012 06:40, nero.23 ha scritto:
> unsigned int x=-8;
qui il tuo compilatore mappa la configurazione di bit di -8 in x


> printf("%d",x);
>
> x, è negativo (-8) e mi aspettavo che mi stampasse 8 con unsigned.
>
> Perchè non mi tronca il segno meno?
>
printf è una funzione di libreria con parametri dal 2^ in poi generici.
Il tipo dei parametri passati li valuta dal primo argomento (%d
significa intero con segno) quindi per lei x è un signed int

[neonano]

Addì lunedì 19 novembre 2012 20:24 fma...@gmail.com scrisse:

> Proprio per i passi citati, se provi a convertire un int32_t ad un
> uint32_t sai cosa succederà (parlando di C99, ovviamente)

Esattamente. Il problema di int, float, double, et cetera è che a
priori non si sa come vengono rappresentati,. qualora questo sia
importante si usano altri tipi.




Addì lunedì 19 novembre 2012 20:24 fma...@gmail.com scrisse:

> In ogni caso concordo con il concetto di fondo: se ti serve un unsigned
> usi un unsigned, altrimenti no, pena: ogni conversione va fatta pensando a
> quello che potrebbe succedere nel peggiore dei casi.

Attenzione però.

unsigned int x=-8;

dichiara una variabile e la inizializza con un ben precisa valore
binario: ultimi tre bit saranno zero, tutti gli altri saranno uno.
Due cose sono non specificate, la lunghezza, per cui tu non sai se
la variabile sarà 0XF8, 0XFFF8, 0XFFFFFFF9, ... e la endianness per
cui tu non sai se le variabile sarà memorizzata come
0XF8 0XFF 0XFF 0XFF oppure 0XFF 0XF0 0XFF 0XFF oppure
0XFF 0XFF 0XFF 0XF8.

Ma fai attenzione, l'incertezza ed il pericolo ci sono nelle
situazioni in cui la taglia e la endianness hanno importanza, se
tu vuoi solo che gli ultimi tre bit siano zero e gli altri uno
indipendentemente dalla grandezza non vedo cosa ci sia di male in:

unsigned int x=-8;

[neonano]

Addì lunedì 19 novembre 2012 21:01 enoquick scrisse:

> Per tè che che forse non conosci altri linguaggi
> In Ada ad esempio per la seguente dichiarazione
>
> u : positive := -1;
>
> il compilatore segnala:
>
> warning: "Constraint_Error" will be raised at run time

Non vedo cosa ci appizzano altri linguaggi. L'errore dell'OP
sta nelle printf, cosa che tu non proprio notato.


Se poi hai semplicemente voluto dire che il compilatore potrebbe
segnalare un warning (per default il compilatore non segnala warning)
al tempo di compilazione e potresti avere un bug dovuto alla
imprevedibilità del risultato, bene avresti dovuto scrivere questo.


Ma forse sono stato precipitoso, forse volevi solo dire che in altri
linguaggi un tale assegnamento non sarebbe stato ammissibile
mentre in C è tutto ben documentato e razionale?





Addì lunedì 19 novembre 2012 21:01 enoquick scrisse:

> Lo standard non parla, giustamente, di numero di bit
>
> Ma dice quale deve essere il comportamento in caso di troncamento o no
> Infatti aggiunge anche questo:

> ...

Come ho già accennato in un'altro articolo, i problemi nascono quando
ti aspetti una certa cosa (p.e. interi a 32 bit su una macchina little
endian) ma ne hai un'altra (p.e. interi a 16 bit su una macchina big
endian), questo non perché gli standard del C non siano chiari o
imprecisi o aleatori, ma perché i programmi (e i programmatori)
viaggiano da una macchina ad un'altra.

[enoquick]

Il 19/11/2012 15:48, neonano ha scritto:
> Addì lunedì 19 novembre 2012 21:01 enoquick scrisse:
>
>> Per tè che che forse non conosci altri linguaggi
>> In Ada ad esempio per la seguente dichiarazione
>>
>> u : positive := -1;
>>
>> il compilatore segnala:
>>
>> warning: "Constraint_Error" will be raised at run time
>
>
> Non vedo cosa ci appizzano altri linguaggi. L'errore dell'OP
> sta nelle printf, cosa che tu non proprio notato.

Se non lo capisci rileggiti quello ho postato prima e la tua risposta.
La discussione non era sulla printf che avevo perfettamente notato e a
suo tempo avevo risposto a chi aveva postato il problema, ma su quell'
assegnamento.

>
>
> Se poi hai semplicemente voluto dire che il compilatore potrebbe
> segnalare un warning (per default il compilatore non segnala warning)
> al tempo di compilazione e potresti avere un bug dovuto alla
> imprevedibilità del risultato, bene avresti dovuto scrivere questo.

Non parlavo del C (è discutibile se considerare il C un linguaggio di
alto livello ai giorni nostri, è piu un assembler portabile)

In Ada addirittura il risultato non è imprevedibile

warning: "Constraint_Error" will be raised at run time

Significa che in esecuzione si avrà il sollevamento di una eccezione di
nome Constraint_Error

>
>
> Ma forse sono stato precipitoso, forse volevi solo dire che in altri
> linguaggi un tale assegnamento non sarebbe stato ammissibile

Infatti, Ada è un linguaggio progettato per risolvere problemi di ben di
più alto livello che scrivere drivers, tanto per capirci

> mentre in C è tutto ben documentato e razionale?

Se tutto è documentato e razionale non lo so
Fatto sta che in C ansi hanno previsto alcuni comportamenti che devono
avere dei compilatori invece che lasciarli semplicemente indefiniti o
implementation defined.
Un esempio è l' assegnamento di un signed in un unsigned.

[neonano]

Addì lunedì 19 novembre 2012 23:28 enoquick scrisse:

> Se non lo capisci rileggiti quello ho postato prima e la tua risposta.
> La discussione non era sulla printf che avevo perfettamente notato e a
> suo tempo avevo risposto a chi aveva postato il problema, ma su quell'
> assegnamento.

A suo tempo? Alle nove e mezzo di sera? L'articolo dell'OP
è stato postato nella pausa pranzo.

[neonano]

Addì lunedì 19 novembre 2012 23:28 enoquick scrisse:

> Non parlavo del C (è discutibile se considerare il C un linguaggio di
> alto livello ai giorni nostri, è piu un assembler portabile)

Vabbè, Dedicati ad ADA e lascia stare il allora.

[neonano]

Addì lunedì 19 novembre 2012 23:28 enoquick scrisse:

> Se non lo capisci rileggiti quello ho postato prima e la tua risposta.

Sinceramente stiamo esagerando. senza polemiche, non voglio farne
nè era mia intenzione farle. Stiamo discutendo di cose assolutamente
irrilevanti. La mia intenzione era solo dire che discutere sul warning,
su errori a tempo di compilazione e simili sono questioni di lana
caprina, anzi ancora meno importante: la lana caprina, il cosidetto
cachemire, è una buona lana. abbiamo perso di vista il tema:

unsigned int x=-8;
printf("%d",x);

La printf stampa un intero con segno, deve essere:

printf("%ud",x);

Quanto a:

unsigned int x=-8;

è una istruzione perfettamente lecita in C ma è pericolosa se non
si sa esattamente ciò che si fa, come tutto in C.

[Jack]

neonano <neo...@mi5.uk> wrote:

> unsigned int x=-8;
>
> � una istruzione perfettamente lecita in C ma � pericolosa se non
> si sa esattamente ci� che si fa, come tutto in C.

veramente si sa esattamente cosa fa, se si conosce il compilatore.

Ciao Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

[mallin.shetland]

Addì Tue, 20 Nov 2012 09:51:58 +0100 Jack scrisse:

> veramente si sa esattamente cosa fa, se si conosce il compilatore.

fatto bene a puntualizzare

[enoquick]

E perchè ?
Non ho mai considerato il C un linguaggio di serie B

[enoquick]

Il 20/11/2012 01:12, neonano ha scritto:
> Addì lunedì 19 novembre 2012 23:28 enoquick scrisse:
>
>> Se non lo capisci rileggiti quello ho postato prima e la tua risposta.
>
>

> è una istruzione perfettamente lecita in C ma è pericolosa se non
> si sa esattamente ciò che si fa, come tutto in C.
>

Fa piacere che affermi ciò, visto che avevi affermato che il risultato
era imprevedibile
Come ha detto Jack nella sua risposta si sa cosa fa se si conosce il
compilatore

[enoquick]

A suo tempo non significa immediatamente

[fma...@gmail.com]

Faccio reply qui ma è un'osservazione più generale.
Non capisco il perché di tutto questo discorso.
Per quanto mi riguarda:
se dichiaro una variabile unsigned devo assegnare un valore unsigned, punto.
Se questo, da qualche parte, non succede, c'è un errore logico nel codice, e
va sistemato! Questo considerando anche che, se voglio qualcosa di particolare,
ci sono funzioni specifiche per ottenere lo stesso risultato in maniera pulita,
comprensibile e portabile.
Conoscere quello che fa il proprio compilatore in quello specifico caso,
quindi, è inutile!

Ciao!

[enoquick]

Il 20/11/2012 10:17, fma...@gmail.com ha scritto:
> On Tuesday, November 20, 2012 3:32:57 PM UTC+1, enoquick wrote:
>> Il 20/11/2012 00:28, neonano ha scritto:

>>> Addě lunedě 19 novembre 2012 23:28 enoquick scrisse:

>>>> Se non lo capisci rileggiti quello ho postato prima e la tua risposta.
>>>> La discussione non era sulla printf che avevo perfettamente notato e a
>>>> suo tempo avevo risposto a chi aveva postato il problema, ma su quell'
>>>> assegnamento.
>>
>>> A suo tempo? Alle nove e mezzo di sera? L'articolo dell'OP

>>> č stato postato nella pausa pranzo.

>>
>> A suo tempo non significa immediatamente
>

> Faccio reply qui ma č un'osservazione piů generale.

> Non capisco il perché di tutto questo discorso.
> Per quanto mi riguarda:
> se dichiaro una variabile unsigned devo assegnare un valore unsigned, punto.

> Se questo, da qualche parte, non succede, c'č un errore logico nel codice, e

> va sistemato! Questo considerando anche che, se voglio qualcosa di particolare,
> ci sono funzioni specifiche per ottenere lo stesso risultato in maniera pulita,
> comprensibile e portabile.
> Conoscere quello che fa il proprio compilatore in quello specifico caso,

> quindi, č inutile!
>
> Ciao!
>

Il discorso č semplice
L' amico Neonano aveva affermato che assegnare un numero negativo ad un
unsigned era un risultato imprevedibile.
Ho fatto osservare che lo std prevede alcuni comportamenti da parte del
compilatore perfettamente prevedibili e questo era uno di quei casi,
tutto qua.
Tu consideri assegnare un numero negativo ad unsigned una cosa da non
fare, ma invece questo č un ragionamento che puň avere un senso in un
linguaggio che č un assembler portabile e se ragioni a livello di bit e
bytes

Es:

unsigned mask = -1;

Dal mio punto di vista crea una maschera di bit tutti a 1, perfettamente
logico.
Ok, lo puoi fare anche cosi:

unsigned mask = 0xFFFFFFFF;

Ma questo non č portabile perchč assumi che un unsigned sia di 4 bytes.
Ed ecco che assegnare -1 ad un unsigned č un modo per rendere il codice
indipendente dalla size dell' unsigned quindi portabile e che assume un
ben preciso significato logico se si ragiona in termini di bit.

[fma...@gmail.com]

On Tuesday, November 20, 2012 5:54:23 PM UTC+1, enoquick wrote:
> Il 20/11/2012 10:17, fma...@gmail.com ha scritto:

> > Faccio reply qui ma è un'osservazione più generale.

> > Non capisco il perché di tutto questo discorso.
> > Per quanto mi riguarda:
> > se dichiaro una variabile unsigned devo assegnare un valore unsigned, punto.

> > Se questo, da qualche parte, non succede, c'è un errore logico nel codice, e

> > va sistemato! Questo considerando anche che, se voglio qualcosa di particolare,
> > ci sono funzioni specifiche per ottenere lo stesso risultato in maniera pulita,
> > comprensibile e portabile.
> > Conoscere quello che fa il proprio compilatore in quello specifico caso,

> > quindi, è inutile!
> > Ciao!
>
> Il discorso è semplice

> L' amico Neonano aveva affermato che assegnare un numero negativo ad un
> unsigned era un risultato imprevedibile.
> Ho fatto osservare che lo std prevede alcuni comportamenti da parte del
> compilatore perfettamente prevedibili e questo era uno di quei casi,
> tutto qua.
>
> Tu consideri assegnare un numero negativo ad unsigned una cosa da non

> fare, ma invece questo è un ragionamento che può avere un senso in un
> linguaggio che è un assembler portabile e se ragioni a livello di bit e

> bytes
> Es:
> unsigned mask = -1;
> Dal mio punto di vista crea una maschera di bit tutti a 1, perfettamente
> logico.
> Ok, lo puoi fare anche cosi:
> unsigned mask = 0xFFFFFFFF;

> Ma questo non è portabile perchè assumi che un unsigned sia di 4 bytes.
> Ed ecco che assegnare -1 ad un unsigned è un modo per rendere il codice

> indipendente dalla size dell' unsigned quindi portabile e che assume un
> ben preciso significato logico se si ragiona in termini di bit.
>

E' questione di gusti..
Quello che dici di solito si fa con -1 perché funziona sempre, mentre cose come:
unsigned long v = ~0u;
oppure
unsigned int v = ~0;
non funzionano sempre (il primo per il numero di bit (int può avere meno bit di
long), il secondo per la rappresentazione (non è detto che sia in complemento
a due)).
Sinceramente quando programmo codice che usa maschere (e quindi, di riflesso,
che mi aspetto sia portabile su più piattaforme "risicate") mi definisco in
un .h i tipi e le maschere con dei typedef e delle define così come mi aspetto
per ogni macchina target (e il target va specificato in compilazione! ;)) e uso
quelle nel codice: in questo modo racchiudo la "logica macchina" in un file e
posso usare la "logica umana" (quella che descrivevo prima, unsigned con
unsigned, signed con signed) in tutti gli altri moduli.
Ciao!

[enoquick]

Anche l' assegnamento -1 funziona per rappresentare una maschera di
tutti 1 proprio perchè i negativi vengono rappresentati in complemento a 2
Se la rappresentazione interna non fosse a complemento a 2 il giochetto
non vale più (la portabilità salta) sia per il ~0 (come fai notare) che
il -1.
Per fortuna non credo che esistano macchine, se non nei musei, che non
usano il complemento a 2.
Forse i mainframe IBM e Siemens ma il loro OS è scritto in assembler e
per interfacciarsi con le chiamate di sistema si usa sempre l' assembler.

> Sinceramente quando programmo codice che usa maschere (e quindi, di riflesso,
> che mi aspetto sia portabile su più piattaforme "risicate") mi definisco in
> un .h i tipi e le maschere con dei typedef e delle define così come mi aspetto
> per ogni macchina target (e il target va specificato in compilazione! ;)) e uso
> quelle nel codice: in questo modo racchiudo la "logica macchina" in un file e
> posso usare la "logica umana" (quella che descrivevo prima, unsigned con
> unsigned, signed con signed) in tutti gli altri moduli.
> Ciao!
>

Si, in generale lo faccio anch'io, non credere che non definisca header
di quel tipo.
Comunque se vuoi una maschera di tutti 1 senza usare -1 o ~0 c'è la
libreria standard.
Le costanti ULONG_MAX e UINT_MAX sono lì apposta