[C] free()

[Tommo]

Originariamente inviato da bancodeipugni

in effetti malloc() come open() e fopen() andrebbe sempre controllata a scanso di cantonate oltre che castata (castata, non castrata )

Onestamente controllare malloc() e' al limite della paranoia...

-sia iOS che Android hanno una gestione estremamente aggressiva della memoria e il malloc che fa traboccare il vaso non ritorna e causa la terminazione del programma.
Il programma puo' anche essere terminato a necessita' dall'OS molto prima che succeda, e in realta' quello che succede e' quasi sempre questo.

-su windows da XP in poi non e' possibile ottenere null a meno di non superare la dimensione massima dell'allocazione, tutto il resto va in paging... ok, a un certo punto crasha, ma parliamo di cosi' tanta memoria allocata e usata tutta assieme che non sara' certo un if a salvare il programma (e il sistema operativo)

-su Mac idem

-su Linux idem e l'if e' anche inutile di fronte a quel bug

-su console la dimensione e' costante e se finisci la memoria hai fatto tu male i conti e non dovrebbe mai accadere, wrappare malloc in una macro che asserta il puntatore e' piu' che sufficiente, quando proprio non c'e' un malloc custom

In sostanza ha senso controllare in alcuni ambiti estremamente ristretti tipo embedded, ma nel caso generale non ha veramente senso sporcare il codice tentando di salvare una situazione che in ogni caso e' compromessa e puo' solo essere il risultato di un bug parecchio brutto.

[WarDuck]

Originariamente inviato da Oceans11

Stavo facendo qualche prova per vedere il comportamento e le soglie sul mio sistema:

Assolutamente strano!
Facendo un paio di conti a braccio, ho circa 7.5GB di memoria disponibile in userspace, allocando 10 MB alla volta mi aspettavo di terminare la memoria in 750 chiamate a malloc, senza considerare l'overcommit.
Con quest'ultimo, essendo la ratio a 50, dovrebbe terminare a total_memory+total_memory*0.5+swap_space = 7.5+3.7+0 = 11GB circa, quindi circa 1100 chiamate.
Stranamente, cambiando SIZE il risultato è sempre 65515.
E tanto per togliermi i dubbi sulla page size, 65515 * 4k fa tipo 256MB, non diversi GB.

Qualcuno mi dice dove sbaglio a fare i conti?
O del perchè il programma non sembra mostare il comportamento dichiarato nelle pagine di manuale di malloc?

Penso sia dovuto ad una strategia opportunistica nella scrittura delle pagine di memoria (una sorta di copy-on-write).

Cioè una pagina viene effettivamente consumata se tu ci scrivi dentro qualcosa, e nel tuo codice questo non avviene mai.

Probabilmente quando tu fai una malloc il sistema è abbastanza intelligente da non consumare memoria fin tanto che tu non ci scrivi dentro.

Fai una prova a scriverci qualcosa dentro (anche un solo carattere), vedi se cambia qualcosa.

[Oceans11]

Originariamente inviato da WarDuck

Penso sia dovuto ad una strategia opportunistica nella scrittura delle pagine di memoria (una sorta di copy-on-write).

Cioè una pagina viene effettivamente consumata se tu ci scrivi dentro qualcosa, e nel tuo codice questo non avviene mai.

Probabilmente quando tu fai una malloc il sistema è abbastanza intelligente da non consumare memoria fin tanto che tu non ci scrivi dentro.

Fai una prova a scriverci qualcosa dentro (anche un solo carattere), vedi se cambia qualcosa.

Il cow me l'ero proprio dimenticato, ho fatto il test che ti dà perfettamente ragione:

Allocation [1] 899 killed ./test

Originariamente inviato da Antonio23

su tutte le codebase in ambito industriale in cui ho lavorato ho sempre visto il void* castato esplicitamente al tipo di destinazione, per la suddetta ragione. Se non casti, il codice non passa la code review, quindi non sono semplicemente gusti.

Programmo in C per diletto, quindi non so nulla di code review e di ambito industriale.
Chiarisco che ho detto che il cast "aggiunge codice" (e da qui a mio parere la diminuzione di leggibilità) "inutile" visto che è prevista dal linguaggio la promozione del tipo void* in qualsiasi altro tipo (il cast è implicito).
Quindi chiedo, come mai in questi ambiti ci sono tali richieste?

[Oceans11]

Originariamente inviato da Antonio23

perché non sei il solo a lavorare, a debuggare e mantenere parti di codice, e tutto quello che può aumentarne la leggibilità a la manutenibilità è fondamentale. in un altro post qui ho letto una cosa del tipo "l'importante è che funzioni"... quando hai a che fare con progetti veri il fatto che qualcosa funzioni è dato per scontato, l'importante è avere codice che sia facilmente manutenibile indipendente da chi ci sta lavorando sopra...

E su questo siamo d'accordo, il problema qua sembra essere la definizione di "leggibile"
Fammi capire, ci deve essere qualcuno che stabilisca alcuni standard tra tutti i programmatori, no?

[mone.java]

Originariamente inviato da Oceans11

E su questo siamo d'accordo, il problema qua sembra essere la definizione di "leggibile"
Fammi capire, ci deve essere qualcuno che stabilisca alcuni standard tra tutti i programmatori, no?

penso che tra almeno quelli di un azienda si. Se io fossi un team leader imporrei un certo stile di programmazione per tutti (ovviamente discusso con il team stesso).. Come la nomenclatura delle variabli/funzioni/classi (nel caso il linguaggio abbia le classi)...
Purtroppo non sono ancora un team leader

[mone.java]

Originariamente inviato da Antonio23

ho letto una cosa del tipo "l'importante è che funzioni"...

I soggetti di questo tipo li chiuderei in galera e getterei la chiave onde evitare che inquinino il mondo con il codice.