info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Spreco di memoria e minaccia alla sicurezza
5 views
Skip to first unread message
guido84
Jun 12, 2017, 8:11:02 AM6/12/17
to
In tutto il libro che seguo c'e' in continuazione:
.....
char pippo[81];
.....
Esasperato dal doverlo scegliere prima, ho capito che potrei
metterci un numero molto grande (es. 1000), ma qui su icol.dev mi
e' stato detto di stare molto attento a quel che resta dopo '\0'.
Allora ho fatto la prova con: char pippo[]; e immediatamente gcc
m'ha dato un Warning dicendo che l'array veniva inteso di 1 solo
carattere, pero' il programma funzionava perfettamente lo stesso.
Allora astutissimamente gli ho messo:
char pippo[1];
adesso niente Warning e funzionamento sempre perfetto, anche con
stringhe lunghissime.
La mia domanda e' questa.
Visto che:
- pippo[1] e' un puntatore all' INIZIO della stringa (lo dicono
in altre pagine)
- la fine e' IN OGNI CASO determinata da '\0' o da BLANK (e non
dall'81)
- l'indirizzo fisico del vettore non e' ancora determinato (viene
fissato di volta in volta durante l'esecuzione?),
allora dico: perche' mai nel libro che ho non fanno altro che
scrivere in continuazione "char pippo[81];" ?
Non sarebbe il caso di mettere SEMPRE "char pippo[1];" ?
--
Saluti,
Guido
.....
char pippo[81];
.....
Esasperato dal doverlo scegliere prima, ho capito che potrei
metterci un numero molto grande (es. 1000), ma qui su icol.dev mi
e' stato detto di stare molto attento a quel che resta dopo '\0'.
Allora ho fatto la prova con: char pippo[]; e immediatamente gcc
m'ha dato un Warning dicendo che l'array veniva inteso di 1 solo
carattere, pero' il programma funzionava perfettamente lo stesso.
Allora astutissimamente gli ho messo:
char pippo[1];
adesso niente Warning e funzionamento sempre perfetto, anche con
stringhe lunghissime.
La mia domanda e' questa.
Visto che:
- pippo[1] e' un puntatore all' INIZIO della stringa (lo dicono
in altre pagine)
- la fine e' IN OGNI CASO determinata da '\0' o da BLANK (e non
dall'81)
- l'indirizzo fisico del vettore non e' ancora determinato (viene
fissato di volta in volta durante l'esecuzione?),
allora dico: perche' mai nel libro che ho non fanno altro che
scrivere in continuazione "char pippo[81];" ?
Non sarebbe il caso di mettere SEMPRE "char pippo[1];" ?
--
Saluti,
Guido
Alessandro Pellizzari
Jun 12, 2017, 10:01:25 AM6/12/17
to
On 12/06/17 13:11, guido84 wrote:
> Allora astutissimamente gli ho messo:
> char pippo[1];
> adesso niente Warning e funzionamento sempre perfetto, anche con
> stringhe lunghissime.
Questo perche`, per efficienza, Linux alloca memoria in blocchi di
> Allora astutissimamente gli ho messo:
> char pippo[1];
> adesso niente Warning e funzionamento sempre perfetto, anche con
> stringhe lunghissime.
dimensione fissa (mi pare 4k), quindi finche` i tuoi dati stanno dentro
il blocco, e tu eccedi nell'ultima variabile dichiarata, va tutto bene.
Ma gia` se provi a fare
char pippo[1];
char pluto[1];
Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto.
> allora dico: perche' mai nel libro che ho non fanno altro che
> scrivere in continuazione "char pippo[81];" ?
> Non sarebbe il caso di mettere SEMPRE "char pippo[1];" ?
Il modo giusto e` usare malloc per allocare la memoria che ti serve, e
poi verificare di volta in volta che non la stai eccedendo.
A quel punto pippo diventa davvero un puntatore a un'area dinamica di
memoria, e lo puoi dichiarare con
char *pippo;
Bye.
guido84
Jun 12, 2017, 10:57:51 AM6/12/17
to
Il 12/6/2017 16:01:23 Alessandro Pellizzari scrisse:
pluto (ma 4k sono veramente moltissmi, glieli daro' da file).
>> allora dico: perche' mai nel libro che ho non fanno altro che
>> scrivere in continuazione "char pippo[81];" ?
>> Non sarebbe il caso di mettere SEMPRE "char pippo[1];" ?
>No. Vedi sopra.
>Il modo giusto e` usare malloc per allocare la memoria che ti serve, e
>poi verificare di volta in volta che non la stai eccedendo.
>A quel punto pippo diventa davvero un puntatore a un'area dinamica di
>memoria, e lo puoi dichiarare con
>char *pippo;
Per imparare le funzioni e poi saperle usare, per atoi() ho
cercato di poter dargli la stringa in input:
1. da argv[1], ormai facile: ./prova 111
2. col comando echo, unico modo: ./prova $(echo 111)
3. passandogliela con una pipe: echo 111 | ./prova -
Per fare il 3 (tralasciando per il momento che non so fargli
distinguere "-" da qualsiasi altro carattere diverso da cifre),
non posso (mi sembra!) usare malloc, perche' scanf() non me lo
puo' dire quanto e' lunga prima di riceverla. E per riceverla
deve avere un posto-vettore dove metterla... insomma: il gatto
che si mangia la coda. Percio' ho trovato l'escamotage di pippo[0]
(adesso ho visto che prende anche lo zero).
Ecco il codice.
------
#include <stdio.h>
#include <string.h>
int atoi(char *origine);
char dapipe[0];
int main(int argc, char** argv)
{
int arg1, arg2;
// ./prova (per l'help)
if (argc == 1)
{
printf("\033[33mUsage: Stringa di arg1 in numero allo stdout \033[m \n");
}
else
{
arg1 = atoi(argv[1]);
// echo 123 | ./prova -
if (arg1 == 0)
{
scanf("%s", dapipe);
arg2 = atoi(dapipe);
printf("%d\n", arg2);
}
// Caso ordinario
else
{
printf("%d\n", arg1);
}
}
return 0;
}
----------------
--
Saluti,
Guido
>On 12/06/17 13:11, guido84 wrote:
>> Allora astutissimamente gli ho messo:
>> char pippo[1];
>> adesso niente Warning e funzionamento sempre perfetto, anche con
>> stringhe lunghissime.
>Questo perche`, per efficienza, Linux alloca memoria in blocchi di
>dimensione fissa (mi pare 4k), quindi finche` i tuoi dati stanno dentro
>il blocco, e tu eccedi nell'ultima variabile dichiarata, va tutto bene.
>Ma gia` se provi a fare
>char pippo[1];
>char pluto[1];
>Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto.
TNX! questa me la faccio piu' tardi, voglio fargli sovrascrivere
>> Allora astutissimamente gli ho messo:
>> char pippo[1];
>> adesso niente Warning e funzionamento sempre perfetto, anche con
>> stringhe lunghissime.
>Questo perche`, per efficienza, Linux alloca memoria in blocchi di
>dimensione fissa (mi pare 4k), quindi finche` i tuoi dati stanno dentro
>il blocco, e tu eccedi nell'ultima variabile dichiarata, va tutto bene.
>Ma gia` se provi a fare
>char pippo[1];
>char pluto[1];
>Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto.
pluto (ma 4k sono veramente moltissmi, glieli daro' da file).
>> allora dico: perche' mai nel libro che ho non fanno altro che
>> scrivere in continuazione "char pippo[81];" ?
>> Non sarebbe il caso di mettere SEMPRE "char pippo[1];" ?
>No. Vedi sopra.
>Il modo giusto e` usare malloc per allocare la memoria che ti serve, e
>poi verificare di volta in volta che non la stai eccedendo.
>A quel punto pippo diventa davvero un puntatore a un'area dinamica di
>memoria, e lo puoi dichiarare con
>char *pippo;
cercato di poter dargli la stringa in input:
1. da argv[1], ormai facile: ./prova 111
2. col comando echo, unico modo: ./prova $(echo 111)
3. passandogliela con una pipe: echo 111 | ./prova -
Per fare il 3 (tralasciando per il momento che non so fargli
distinguere "-" da qualsiasi altro carattere diverso da cifre),
non posso (mi sembra!) usare malloc, perche' scanf() non me lo
puo' dire quanto e' lunga prima di riceverla. E per riceverla
deve avere un posto-vettore dove metterla... insomma: il gatto
che si mangia la coda. Percio' ho trovato l'escamotage di pippo[0]
(adesso ho visto che prende anche lo zero).
Ecco il codice.
------
#include <stdio.h>
#include <string.h>
int atoi(char *origine);
char dapipe[0];
int main(int argc, char** argv)
{
int arg1, arg2;
// ./prova (per l'help)
if (argc == 1)
{
printf("\033[33mUsage: Stringa di arg1 in numero allo stdout \033[m \n");
}
else
{
arg1 = atoi(argv[1]);
// echo 123 | ./prova -
if (arg1 == 0)
{
scanf("%s", dapipe);
arg2 = atoi(dapipe);
printf("%d\n", arg2);
}
// Caso ordinario
else
{
printf("%d\n", arg1);
}
}
return 0;
}
----------------
--
Saluti,
Guido
Alessandro Pellizzari
Jun 12, 2017, 12:14:51 PM6/12/17
to
On 12/06/17 15:57, guido84 wrote:
> Il 12/6/2017 16:01:23 Alessandro Pellizzari scrisse:
> Il 12/6/2017 16:01:23 Alessandro Pellizzari scrisse:
>> Ma gia` se provi a fare
>
>> char pippo[1];
>> char pluto[1];
>
>> Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto.
>
> TNX! questa me la faccio piu' tardi, voglio fargli sovrascrivere
> pluto (ma 4k sono veramente moltissmi, glieli daro' da file).
No, in questo caso non serve che allochi 4k.
>
>> char pippo[1];
>> char pluto[1];
>
>> Scrivendo oltre il limite di pippo rischi di sovrascrivere pluto.
>
> TNX! questa me la faccio piu' tardi, voglio fargli sovrascrivere
> pluto (ma 4k sono veramente moltissmi, glieli daro' da file).
Ti basta scrivere 2 caratteri dentro pippo, e il secondo te lo trovi in
pluto.
Questo presupponendo che la memoria venga allocata in ordine. Non so se
le versioni recenti di gcc o del kernel rispettino questa regola o
randomizzino la memoria apposta per evitare buffer overflow.
> Per fare il 3 (tralasciando per il momento che non so fargli
> distinguere "-" da qualsiasi altro carattere diverso da cifre),
> non posso (mi sembra!) usare malloc, perche' scanf() non me lo
> puo' dire quanto e' lunga prima di riceverla. E per riceverla
> deve avere un posto-vettore dove metterla... insomma: il gatto
> che si mangia la coda. Percio' ho trovato l'escamotage di pippo[0]
> (adesso ho visto che prende anche lo zero).
libreria.
Prepari un buffer di (diciamo) 4k. Provi a leggere 4k. Se l'input
finisce prima, ti fermi e analizzi quello che hai, altrimenti allochi
altri 4k, continui a leggere nel nuovo buffer, ecc. ecc. finche` non
raggiungi la fine dell'input. A quel punto sai quanto hai letto e lo
processi.
In alternativa allochi 4k, provi a leggere, se non basta usi realloc per
allargare il buffer (di solito si raddoppia ogni volta), e vai avanti
finche` l'input non e` finito.
Il tuo prossimo problema e` che atoi va in overflow superati i 9
miliardi di miliardi (una ventina di cifre, su architettura 64bit),
quindi leggere piu` di 20-25 bytes e` comunque inutile, e dobresti usare
una libreria come bcmath.
Hai voluto lavorare a basso livello? E adesso pedala! ;D
Bye.
enoquick
Jun 12, 2017, 10:40:47 PM6/12/17
to
Il 12/06/2017 07:11, guido84 ha scritto:
> In tutto il libro che seguo c'e' in continuazione:
> ......
> In tutto il libro che seguo c'e' in continuazione:
> char pippo[81];
> ......
di caratteri
Ma per capirlo meglio postare un esempio di codice.
guido84
Jun 13, 2017, 3:28:21 AM6/13/17
to
Il 13/6/2017 04:40:46 enoquick scrisse:
Be' me l'ha spiegato Alessandro P., una stringa e' un puntatore
all'inizio piu' \0 alla fine. Si puo' mettere dentro un array
statico, oppure allocando (dinamicamente) spazio in memoria con
malloc, dal puntatore fino al numero di byte che si danno a
malloc stesso.
Un array invece non e' detto che abbia \0, e' semplicemente un
puntatore alla prima cella piu' il numero di celle riservate a
lui, non importa se e cosa ci sia gia' dentro o ci si metta.
Adesso devo sviscerarlo bene, ma ho gia' fatto il malloc per i
caratteri, poi lo faro' per gli interi e i reali.
Questo l'ho trovato fatto, devo capire ancora il ruolo delle
tonde (char *) prima di malloc(), e anche le doppie parentesi
di if, spero-penso che siano come per la bash:
------------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
char *stringa;
//if((stringa = (char *) malloc(2147483647)) == NULL) // 0x7fff.ffff
if ((stringa = (char *) malloc(0x09fffffff)) == NULL)
{
printf("memoria insufficiente \n");
exit(1);
}
printf("OK \n");
return 0;
}
------------
Non so perche' con gli esa ne prende di piu': 9fff.ffff contro
gli equivalenti di 7fff.ffff coi decimali.
--
Saluti,
Guido
all'inizio piu' \0 alla fine. Si puo' mettere dentro un array
statico, oppure allocando (dinamicamente) spazio in memoria con
malloc, dal puntatore fino al numero di byte che si danno a
malloc stesso.
Un array invece non e' detto che abbia \0, e' semplicemente un
puntatore alla prima cella piu' il numero di celle riservate a
lui, non importa se e cosa ci sia gia' dentro o ci si metta.
Adesso devo sviscerarlo bene, ma ho gia' fatto il malloc per i
caratteri, poi lo faro' per gli interi e i reali.
Questo l'ho trovato fatto, devo capire ancora il ruolo delle
tonde (char *) prima di malloc(), e anche le doppie parentesi
di if, spero-penso che siano come per la bash:
------------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
char *stringa;
//if((stringa = (char *) malloc(2147483647)) == NULL) // 0x7fff.ffff
if ((stringa = (char *) malloc(0x09fffffff)) == NULL)
{
printf("memoria insufficiente \n");
exit(1);
}
printf("OK \n");
return 0;
}
------------
Non so perche' con gli esa ne prende di piu': 9fff.ffff contro
gli equivalenti di 7fff.ffff coi decimali.
--
Saluti,
Guido
Alessandro Pellizzari
Jun 13, 2017, 5:16:03 AM6/13/17
to
On 13/06/17 08:28, guido84 wrote:
> Questo l'ho trovato fatto, devo capire ancora il ruolo delle
> tonde (char *) prima di malloc(),
malloc torna un (void *) (un puntatore generico)
> Questo l'ho trovato fatto, devo capire ancora il ruolo delle
> tonde (char *) prima di malloc(),
Mettendo (char *) prima forzi il compilatore a gestirlo come un
puntatore a char, abilitando check e ottimizzazioni aggiuntive.
> e anche le doppie parentesi
> di if, spero-penso che siano come per la bash:
malloc()) prima di confrontarla con null.
Per chiarezza e` meglio "esplodere" il comando cosi`:
char *stringa = (char *)malloc(2147483647);
if (stringa == null) { ... }
Ochio che stai allocando 2GB di memoria, con quella riga.
Funziona solo perche` Linux non alloca veramente la memoria finche` non
ci scrivi sopra, ma altri S.O. potrebbero allocarla veramente anche se
non ti serve.
Bye.
0 new messages