Newsgroup: it.comp.lang.c
Titolo: Boh?

Chi sa dirmi perche' il codice allegato con il DEV-CPP mi da errore
mentre con il BCC55 va bene?
Grazie a chi riesce a togliermi il dubbio.
#include <stdio.h>
unsigned char *c;
int main()
{
  c[0]="S";
  return 0;
}





 ha scritto nel messaggio
news:jnEgb.19350$e6.6...@twister2.libero.it...

Mmm...non capisco....
vedo usata una posizione di  un vettore ( c[0]) senza vederne dichiarato
uno.
E poi "unsigned" non viene usato per int, float e compagnia bella , ad
esclusione proprio del tipo di dato "char" ??
...e i caratteri non devono essere racchiusi tra apici invece che
virgolette?:-?
Oddio... non ditemi che quella roba sopra è tutta lecita che mi metto a
piangere .... illuminatemi please!!!  :_(
Grazie a tutti
Simone
P.s. misà che non ho capito nulla di quel pezzo di codice , eh? :-(


Provo a dirti cosa mi sembra ci sia di sbagliato e di "poco C" in questo
codice, poi magari qualcuno più esperto mi correggerà.
Posto che anche sul borland (builder, ma il compiler dovrebbe essere lo
stesso) mi da un errore, e per giunta lo stesso del Dev-Cpp, per prima cosa
tu dichiari una variabile (globale) di tipo "puntatore a unsigned char",
mentre dopo con l'assegnamento c[0] = ti riferisci alla cella puntata da c,
senza che essa venga effettivamente allocata. Inolte, assegni a un carattere
una stringa ("s", quindi un char *), tipi tra loro incompatibili. Assegnare
a un array una stringa attraverso l'operatore = è possibile (se non sbaglio)
solo alla dichiarazione dell'array e se quest'ultimo è statico. Poi,
includere stdio.h in questo specifico caso non serve a nulla...
'sera lietissima, Marco

Carlo wrote:
  unsigned char *c;
  int main(int,char*[])
  {
    c = "S";
    return 0;
  }
prova cosi ...
ciao

 }
Uso di un puntatore che non punta ad una struttura dati (in questo caso un
carattere) dinamica o statica???? brrrrrrrr ho i brividi
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Un giorno forse gli uomini saranno in grado di comprendersi

 P.s. misà che non ho capito nulla di quel pezzo di codice , eh? :-(
imHo lo hai capito eccome :-)
ciao enos


thaaaanks! :**)
:_)
:_)

 Unsigned char va da 0 a 255, char va da -128 a 127
Davvero? Il documento dello standard afferma ben altro.
-- 
Enrico `Trippo' Porreca



Kernighan & Ritchie (seconda edizione), pag. 43:
Se i char occupano 8 bit, le variabili unsigned char assumono valori
compresi fra 0 e 255, mentre quelle di tipo signed char vanno da -128 a
+127 (in una macchina che lavori in complemento a due).
--Lorenzo

 +127 (in una macchina che lavori in complemento a due).
Infatti questa frase e` corretta, ma non ha valore universale.
Ci sono ben due `se':
     1) *se* i char occupano 8 bit
     2) *se* la macchina lavora in complemento a due
*allora* gli unsigned char etc...
Lo standard non richiede ne` (1) ne` (2), anche se abitualmente valgono 
entrambe al giorno d'oggi.
-- 
Enrico `Trippo' Porreca


d'accordo, ma visto che
1) il problema era stato risolto
2) con quasi certezza chi ha iniziato il thread si trovava a lavorare
nelle condizioni citate dal K&R
era inutile fare un followup della risposta di enos_it, a meno che non
volessi essere oltremodo precisino. :)
ciao,
--Lorenzo

 volessi essere oltremodo precisino. :)
Lo scopo era proprio quello di essere pignolo :-)
Dato che nell'esempio in questione il range dei char non era coinvolto, 
ma era stato ugualmente tirato in ballo in maniera non precisa, ho 
semplicemente segnalato la cosa.
Siccome non ci vuole tanto ad esempio ad usare un tipo con un range piu` 
ampio di signed char se ho bisogno di contenere il valore -128 (che lo 
standard non richiede sia nel range dei signed char), non vedo perche` 
non farlo (questo ovviamente a meno di esigenze molto particolari). In 
questo modo il programma potrebbe girare anche su macchine preistoriche 
con aritmetica in complemento a uno (o segno e valore assoluto).
Inoltre, tempo fa avevo letto di un sistema embedded (moderno) in cui i 
char sono di 16 bit, perche` l'hardware non e` in grado di accedere a 
dati di dimensioni piu` piccole.
-- 
Enrico `Trippo' Porreca