Newsgroup: it.comp.lang.c
Titolo: conversione da char* a char

ciao a tutti.
sono ancora agli inizi e vorrei una mano con sti cavolo di puntatori, se
possibile.
ho una funzione che mi restituisce un *char, mentre a me serve un char[].
mi servirebbe cioe' un qualcosa che prende la stringa puntata da quel
*char e me la mette in un 
char chrOut[40];
o in un
char chrOut;
cioe' qualcosa del tipo
char *chrRet;
char chrOut[40];
chrRet=funzione();
chrOut=qualchecosa chrRet;
mi sapreste dare una mano?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 char chrOut;
Le idee sono molto confuse però... quelle due variabili sono di tipo 
diverso non puoi assegnare l'una all'altra (si può sempre forzare, ma 
non vedo validi motivi per fare una cosa del genere)
Ciao

 char chrOut[40];
char *p;
char chrOut[40];
int i;
for (i=0;i<40;++i)
   chrOut[i]=p[i];
// E.

 
strcpy ?

 č completamente uguale.
Non e' vero. IMHO devi riguardare per bene le differenze fra dichiarare
un array e dichiarare un puntatore.
-- 
-riko

Enrico Franchi ha scritto:

Non č che io abbia mai studiato la definizione formale del linguaggio; 
ti riferisci al fatto che nelle dichiarazioni ho implicitamente allocato 
memoria? e quindi al fatto che non posso fare le stesse cose con a1 e a2
se sono dichiarati cosě:
char a1[10];
char* a2;
ovviamente qui non posso dereferenziare a2 ma a1 si.
Scusami se approfitto... ma nel mio modello mentale qui a1 č un 
puntatore come lo č a2 solo che quest'ultimo non punta a memoria allocata.

 puntatore come lo č a2 solo che quest'ultimo non punta a memoria allocata.
No. Faccio prima a fare un mini pappardello che a risponderti domanda
per domanda. 
In C array e puntatori *sono* cose distinte. La confusione nasce perche'
in molti casi (quasi tutti, in effetti) un array "decade" al puntatore
al primo membro.
In particolare per a1 il compilatore alloca spazio per 10 char (di fatto
di piu', ma questo non ci interessa). Viceversa nel secondo caso alloca
spazio solo per un puntatore a carattere.
Se facessi sizeof(a1) e sizeof(a2) avresti per esempio dimensioni
diverse. Ovviamente se passi a1 ad una funzione, a1 decade a puntatore e
dentro la funzione lo manipoli come un puntatore. 
Nel caso di OP la differenza e' ancora piu' rilavante. Considera questo
programma:
#include <stdio.h>
int main ()
{
        char f[] = "foo foo foo";
        char *b = "bar bar bar";
 
        printf("%lu, %lu\n", sizeof(f), sizeof(b));
 
        f[1] = 'a';
        puts(f);
 
        /* boom */
        b[1] = 'e';
        puts(b);
 
        return 0;
}
Quando dichiari f, il compilatore alloca spazio per un array grande
abbastanza per contenere "foo foo foo" e ce li mette dentro. Questa
memoria e' sullo stack ed e' *mutabile*. In particolare quando piu'
avanti la vai a modificare, non succede nulla.
Viceversa per b il compilatore alloca memoria per "bar bar bar" dove
vuole lui (e in particolare essendo un letterale stringa, questo e'
ripicamente in TEXT) in una zona potenzialmente read only. E' infatti
undefined behaviour fare come faccio poi, ovvero andare a modificare la
stringa. Infatti il programma qua per dire scoppia.
Infatti la dichiarazione "corretta" avrebbe dovuto essere:
        const char *b = "bar bar bar";
E il compilatore ti avrebbe impedito di fare la cappella di cui sotto.
-- 
-riko

 allocata.
int main() 
{
        char a1[] = "ciao";
        char *a2  = "ciao";
 
        a1[0] = 'C'; /* OK */
        a2[0] = 'C'; /* undefined behavior */
        a2 = a1;     /* OK */
        a1 = a2;     /* Error */
        /* sizeof(a1) = 5 (sempre) */
        /* sizeof(a2) = 4 (o qualchecosa altro) */
}
Un array:
             +---+---+---+---+---+---+
          a: | h | e | l | l | o |\0 |
             +---+---+---+---+---+---+
Un puntatore:
             +-----+     +---+---+---+---+---+---+
          p: |  *======> | w | o | r | l | d |\0 |
             +-----+     +---+---+---+---+---+---+
Saluti dalla germania
cc

           p: |  *======> | w | o | r | l | d |\0 |
In questo spiegazione "grafica" l'unica differenza è che non hai messo 
l'indirezione, ma è una scelta artificiale.
Che io ricordi a[12] è preprocessato in *(a+sizeof(a)*12) .
Mi sembra invece più pertinente la spiegazione di Enrico riguardo le 
stringe che in C sono costanti e immutabili (did you say 
NSMutableString?).

(did you say NSMutableString?).
Ah, quanto vorrei fare in Obj-C l'aggeggiazzo che mi sto smazzando in
C++. :P
Fra pochi istanti sto per iniziare una lunga sessione a gdb che non so
bene quando finira'. :P
-- 
-riko

 bene quando finira'. :P
Recita il tuo mantra.

 in che cosa?
In un while, ma forse ho la memoria nebulosa come Testa di Cavallo.
Il senso era che la macchina C non disponeva di una struttura con i 
cicli numerati, come il FOR NEXT del BASIC e che si fosse ovviato a 
questo introducendola col preprocessore. Da questo poi deriva il fatto 
che il ciclo for in C ha la condizione così "flessibile" e può mancare 
di inizializzazione e incrementeo, perché non è un ciclo fisso vero e 
proprio.
for ( A; B; C;) D;  -->   A; while( B; ) { D; C; }

 Recita il tuo mantra.
Dhn p'r' ha gvmvb pba yn oneon ovnapn pur nffrevfpr qv aba nffbzvtyvner
nq ha pnar ar' nq ha cbepb.
-- 
-riko

 for ( A; B; C;) D;  -->   A; while( B; ) { D; C; }
Oggi direi che il problema non si pone: entrambi i costrutti vengono
tradotti in qualche rappresentazione intermedia (direi per darci un idea
un three address code oppure un albero) e di fatto generano
probabilmente lo stesso codice.
Si, comunque sono equivalenti ovviamente.
-- 
-riko