[gcc] option pour prevenir les ecritures memoire interdites ?
Le
Erwann
Imaginons que j'aie du code qui ressemble a ca :
char *data ;
data = "Bonjour" ;
En general, ca va marcher vu la tres faible quantite d'octets
necessaires. Le probleme c'est que lorsqu'on commence a travailler
avec des mallocs, il arrive qu'on se plante et que le programme
aussi d'ailleurs, en faisant une erreur de segmentation.
Le probleme qui arrive alors est de localiser la source de
l'erreur, qui n'apparait pas forcement lors de l'execution la ou
le code est defaillant.
Existe-t-il quelque chose (peut-etre une option dans gcc) qui
stoperait le programme (comme une erreur de segmentation) mais
immediatement, des lors que le programme veut ecrire dans une zone
non reservee par le malloc, meme si en pratique cette zone n'est
pas affectee (et que ca peut donc marcher des fois) ? La localisation
de l'erreur en serait plus facile.
--
Erwann
char *data ;
data = "Bonjour" ;
En general, ca va marcher vu la tres faible quantite d'octets
necessaires. Le probleme c'est que lorsqu'on commence a travailler
avec des mallocs, il arrive qu'on se plante et que le programme
aussi d'ailleurs, en faisant une erreur de segmentation.
Le probleme qui arrive alors est de localiser la source de
l'erreur, qui n'apparait pas forcement lors de l'execution la ou
le code est defaillant.
Existe-t-il quelque chose (peut-etre une option dans gcc) qui
stoperait le programme (comme une erreur de segmentation) mais
immediatement, des lors que le programme veut ecrire dans une zone
non reservee par le malloc, meme si en pratique cette zone n'est
pas affectee (et que ca peut donc marcher des fois) ? La localisation
de l'erreur en serait plus facile.
--
Erwann
Poser une question
Dangereux. Je recommande :
char const *data ;
data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
C'est pas normal. Le programme est buggé, il faut le corriger. C'est
tout.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On
appelle ça 'programmeur'.
En gros, tu écris du code buggé, et tu comptes sur le compilateur pour
t'indiquer où sont les bugs? T'es payé pour faire quoi au juste ?
Pourquoi ne pas écrire du code non buggé tout de suite ? Le code est-il
suffisament modulaire pour qu'on puisse le tester par modules (tests
unitaires).
Les principales causes de bug sont
- Utilisation d'un pointeur non initialisé ou NULL
- Débordement de tableau.
Il faut travailler là-dessus.
--
Emmanuel
si ce meme programmme est lancé deux fois simultanément, "Bonjour" sera-t-il
une seul fois en mémoire ou bien deux fois?
--
gdm
sites liberaux et sites libertariens:
http://www.liberalia.com
http://www.catallaxia.org
Rien de tel en C standard. Pour du vrai simultané, il faut au moins 2
processeurs et le système qui va avec. Pour du pseudo simultané
(multithread mono-processeur), il faut le système qui va bien. Rien à
voir avec le langage C.
Oui, non, peut être... Ca dépend totalement du système.
--
Emmanuel
Impossible à dire. En fait, tu peux même avoir des implémentations où il
sera présent une seule fois... jusqu'au moment (où on écrit dans la chaîne)
où il deviendra présent deux fois !
Et pour être encore plus caustique, avec les objets partagés "à la SunOS",
tu peux même avoir trois copies en mémoire (une copie "originale", protégée
en lecture, et deux copies de travail).
Antoine
Je te vois venir...
Perso, j'attend toujours une option du compilateur pour qu'il me dise
mon avenir... m'enfin -fbounds-check de gcc et autres Valgrind dont il
est question un peu plus loin dans ce forum devraient t'aider.
--
Tek