[gcc] option pour prevenir les ecritures memoire interdites ?
8 réponses
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Delahaye
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ; data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ; data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est tout.
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On appelle ça 'programmeur'.
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.
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
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ;
data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ;
data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est
tout.
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On
appelle ça 'programmeur'.
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.
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.
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est tout.
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On appelle ça 'programmeur'.
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.
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
gdm
Emmanuel Delahaye wrote:
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ; data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ; data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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
Emmanuel Delahaye wrote:
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ;
data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ;
data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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
car une chaine litéralle n'est pas modifiable (pour être simple).
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
Emmanuel Delahaye
gdm a formulé la demande :
char const *data ; data = "Bonjour" ;
si ce meme programmme est lancé deux fois simultanément,
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.
"Bonjour" sera-t-il une seul fois en mémoire ou bien deux fois?
Oui, non, peut être... Ca dépend totalement du système.
--
Emmanuel
gdm a formulé la demande :
char const *data ;
data = "Bonjour" ;
si ce meme programmme est lancé deux fois simultanément,
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.
"Bonjour" sera-t-il
une seul fois en mémoire ou bien deux fois?
Oui, non, peut être... Ca dépend totalement du système.
si ce meme programmme est lancé deux fois simultanément,
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.
"Bonjour" sera-t-il une seul fois en mémoire ou bien deux fois?
Oui, non, peut être... Ca dépend totalement du système.
--
Emmanuel
Antoine Leca
En 40fe571d$0$307$, gdm va escriure:
si ce meme programmme est lancé deux fois simultanément, "Bonjour" sera-t-il une seul fois en mémoire ou bien deux fois?
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
En 40fe571d$0$307$7a628cd7@news.club-internet.fr, gdm va escriure:
si ce meme programmme est lancé deux fois simultanément, "Bonjour"
sera-t-il une seul fois en mémoire ou bien deux fois?
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).
si ce meme programmme est lancé deux fois simultanément, "Bonjour" sera-t-il une seul fois en mémoire ou bien deux fois?
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
Alexandre Bacquart
Erwann wrote:
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.
Je te vois venir...
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.
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
Erwann wrote:
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.
Je te vois venir...
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.
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.
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.
Je te vois venir...
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.
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
Erwann
In article <40fe6b4f$0$4208$, Alexandre Bacquart wrote:
de l'erreur en serait plus facile.
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.
Merci pour Valgrind, je vais jeter un oeil.
In article <40fe6b4f$0$4208$626a14ce@news.free.fr>, Alexandre Bacquart wrote:
de l'erreur en serait plus facile.
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.
In article <40fe6b4f$0$4208$, Alexandre Bacquart wrote:
de l'erreur en serait plus facile.
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.
Merci pour Valgrind, je vais jeter un oeil.
Erwann
In article , Emmanuel Delahaye wrote:
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ; data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ; data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est tout.
Ah bon ? Le programme est bugge ? Ca alors, je ne m'en etais pas apercu dis-donc !
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On appelle ça 'programmeur'.
Tu m'apprends beaucoup de choses dis-moi.
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.
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 ?
Je parlais _eventuellement_ d'une option du compilateur mais ca peut tres bien etre autre chose (cf. Valgrind par exemple). Je ne suis pas paye, je me permets donc de poser des questions debiles.
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.
Je sais bien ce qui peut faire bugger un programme, ce n'etait pas ma
question.
-- Erwann
In article <mn.ab057d47abffbec8.15512@YOURBRAnoos.fr>, Emmanuel Delahaye wrote:
Erwann a formulé la demande :
Imaginons que j'aie du code qui ressemble a ca :
char *data ;
data = "Bonjour" ;
Dangereux. Je recommande :
char const *data ;
data = "Bonjour" ;
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est
tout.
Ah bon ? Le programme est bugge ? Ca alors, je ne m'en etais pas
apercu dis-donc !
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On
appelle ça 'programmeur'.
Tu m'apprends beaucoup de choses dis-moi.
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.
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 ?
Je parlais _eventuellement_ d'une option du compilateur mais ca peut
tres bien etre autre chose (cf. Valgrind par exemple). Je ne suis pas
paye, je me permets donc de poser des questions debiles.
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.
Je sais bien ce qui peut faire bugger un programme, ce n'etait pas ma
car une chaine litéralle n'est pas modifiable (pour être simple).
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.
C'est pas normal. Le programme est buggé, il faut le corriger. C'est tout.
Ah bon ? Le programme est bugge ? Ca alors, je ne m'en etais pas apercu dis-donc !
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.
Ben oui. Faut débugger, tracer, tester, vérifier... C'est un métier. On appelle ça 'programmeur'.
Tu m'apprends beaucoup de choses dis-moi.
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.
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 ?
Je parlais _eventuellement_ d'une option du compilateur mais ca peut tres bien etre autre chose (cf. Valgrind par exemple). Je ne suis pas paye, je me permets donc de poser des questions debiles.
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.
Je sais bien ce qui peut faire bugger un programme, ce n'etait pas ma
question.
-- Erwann
Erwann
In article , Erwann wrote:
Imaginons que j'aie du code qui ressemble a ca :
char *data ; data = "Bonjour" ; [...]
Apres quelques recherches, je suis egalement tombe sur Electric Fence qui a l'air de bien correspondre a ce que je cherche. Aux yeux de certains, je demandais quelque chose d'impossible. Pourtant si ces outils existent, je prefere m'en servir plutot que de passer des heures sur un debugger pour une erreur triviale mais noyee dans le code.
Les gens qui m'ont repondu sont certainement nes en connaissant deje tout du C, mais ce n'est pas mon cas. Mea culpa aussi, j'aurais du consulter le thread commence le 30 juin qui parle exactement de la meme chose. Merci aussi a Alexandre pour les pistes proposees.
-- Erwann
In article <slrncfscoe.89t.ethorava@pxs078.slt.atr.jp>, Erwann wrote:
Imaginons que j'aie du code qui ressemble a ca :
char *data ;
data = "Bonjour" ;
[...]
Apres quelques recherches, je suis egalement tombe sur Electric Fence
qui a l'air de bien correspondre a ce que je cherche. Aux yeux de
certains, je demandais quelque chose d'impossible. Pourtant si
ces outils existent, je prefere m'en servir plutot que de passer
des heures sur un debugger pour une erreur triviale mais noyee
dans le code.
Les gens qui m'ont repondu sont certainement nes en connaissant
deje tout du C, mais ce n'est pas mon cas. Mea culpa aussi, j'aurais
du consulter le thread commence le 30 juin qui parle exactement
de la meme chose. Merci aussi a Alexandre pour les pistes proposees.
Apres quelques recherches, je suis egalement tombe sur Electric Fence qui a l'air de bien correspondre a ce que je cherche. Aux yeux de certains, je demandais quelque chose d'impossible. Pourtant si ces outils existent, je prefere m'en servir plutot que de passer des heures sur un debugger pour une erreur triviale mais noyee dans le code.
Les gens qui m'ont repondu sont certainement nes en connaissant deje tout du C, mais ce n'est pas mon cas. Mea culpa aussi, j'aurais du consulter le thread commence le 30 juin qui parle exactement de la meme chose. Merci aussi a Alexandre pour les pistes proposees.
