En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de l’allouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlse
Après, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de l’allouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlse
Après, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de l’allouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlse
Après, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
In article ,
ja wrote:En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de lallouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlseAprès, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Non, uniquement pour les variables statiques.
Initialiser les variables a une valeur decente par defaut n'est utile
QUE dans certaines conditions.
Dans
{
char *s;
...
s = malloc(qqc);
if (s == NULL) {
...
}
...
}
tu n'as pas besoin d'initialiser s a 0, tout betement parce que ton compilo
est parfaitement capable de te dire si s a ete utilisee sans avoir ete
initialisee.
Apres, si tu es C99 ou plus, un style raisonnable consiste a ne declarer
les variables QUE au moment ou on va les initialiser. Le code precedent
devient
{
char *s = malloc(qqc);
if (s == NULL) {
...
}
...
}
ca ne s'applique pas au noyau d'Open (on a encore une archi sur laquelle
le seul compilo supporte est gcc 2.95... un compilo plus recent fait des
trucs invraisemblablement faux en termes d'optimisation).
(note que ce style est sujet a controverse pour les vieux, qui veulent
absolument declarer toutes les variables en tete de fonction)
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
Visiblement, tu es relativement debutant. Attaquer par le code d'un
noyau n'est pas du tout du tout un bon exemple.
Je te recommande de commencer par apprendre un peu le langage pour de vrai,
par exemple avec le K&R, avant de t'attaquer a des trucs plus complexes.
Cote "securite", de tels conseils sont relativement nocifs.
Les initialisations parasites peuvent donner l'illusion que le code
est propre, alors que des problemes plus sournois s'y cachent.
Pire: les initialisations en plus rajoutent "du bruit" en terme de code
qui au final ne sert pas (parce que ton compilo va bien evidemment
optimiser une double initialisation), et conduisent certaines personnes
a encapsuler leurs allocations dans des grosses macros qui font plein
de trucs et qui cassent tout.
La bonne securite s'obtient generalement en sachant ce qu'on fait, donc
commence par reellement apprendre le langage depuis les bases, puis en
essayant d'ecrire du code le plus clair possible, en evitant d'etre
"cute"...
Le code noyau, pour apprendre a ecrire du code C, c'est pas tip-top. Bon,
tu aurais pu faire pire et regarder le code noyau linux (qui est tellement
noye dans les spinlocks que plus rien n'est visible) ou le code GNU (qui
n'est a peu pres jamais ecrit en C sans au moins trois surcouches de
macros et d'indirections a la con)
In article <46944e48-71e8-473c-81e3-4c85a3cdb522@googlegroups.com>,
ja <ja@px.io> wrote:
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de lallouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlse
Après, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Non, uniquement pour les variables statiques.
Initialiser les variables a une valeur decente par defaut n'est utile
QUE dans certaines conditions.
Dans
{
char *s;
...
s = malloc(qqc);
if (s == NULL) {
...
}
...
}
tu n'as pas besoin d'initialiser s a 0, tout betement parce que ton compilo
est parfaitement capable de te dire si s a ete utilisee sans avoir ete
initialisee.
Apres, si tu es C99 ou plus, un style raisonnable consiste a ne declarer
les variables QUE au moment ou on va les initialiser. Le code precedent
devient
{
char *s = malloc(qqc);
if (s == NULL) {
...
}
...
}
ca ne s'applique pas au noyau d'Open (on a encore une archi sur laquelle
le seul compilo supporte est gcc 2.95... un compilo plus recent fait des
trucs invraisemblablement faux en termes d'optimisation).
(note que ce style est sujet a controverse pour les vieux, qui veulent
absolument declarer toutes les variables en tete de fonction)
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
Visiblement, tu es relativement debutant. Attaquer par le code d'un
noyau n'est pas du tout du tout un bon exemple.
Je te recommande de commencer par apprendre un peu le langage pour de vrai,
par exemple avec le K&R, avant de t'attaquer a des trucs plus complexes.
Cote "securite", de tels conseils sont relativement nocifs.
Les initialisations parasites peuvent donner l'illusion que le code
est propre, alors que des problemes plus sournois s'y cachent.
Pire: les initialisations en plus rajoutent "du bruit" en terme de code
qui au final ne sert pas (parce que ton compilo va bien evidemment
optimiser une double initialisation), et conduisent certaines personnes
a encapsuler leurs allocations dans des grosses macros qui font plein
de trucs et qui cassent tout.
La bonne securite s'obtient generalement en sachant ce qu'on fait, donc
commence par reellement apprendre le langage depuis les bases, puis en
essayant d'ecrire du code le plus clair possible, en evitant d'etre
"cute"...
Le code noyau, pour apprendre a ecrire du code C, c'est pas tip-top. Bon,
tu aurais pu faire pire et regarder le code noyau linux (qui est tellement
noye dans les spinlocks que plus rien n'est visible) ou le code GNU (qui
n'est a peu pres jamais ecrit en C sans au moins trois surcouches de
macros et d'indirections a la con)
In article ,
ja wrote:En fait en lisant qques livres (peut être trop scolaire) j'ai souvent vu
que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL afin de ne pas oublier de lallouer plus tard dans
le code.
Voici deux exemples :
Figure 2.4
http://books.google.fr/books?id=jfn1IAN3dvwC&pg=PT67&lpg=PP1&dq=secure+programming+c&hl=fr du livre "Secure Coding in C and C++"
p337 du livre "Programmation système en C sous Linux" :
http://books.google.fr/books?idçtyMAntgaAC&pg=PA337&dq=malloc+null&hl=fr&sa=X&ei=tQLpUfr8NsnMOM_TgPAK&ved DcQuwUwAA#v=onepage&q=malloc%20null&fúlseAprès, peut être que c'est inutile ? peut être que le compilateur init à
0 par défaut ?
Non, uniquement pour les variables statiques.
Initialiser les variables a une valeur decente par defaut n'est utile
QUE dans certaines conditions.
Dans
{
char *s;
...
s = malloc(qqc);
if (s == NULL) {
...
}
...
}
tu n'as pas besoin d'initialiser s a 0, tout betement parce que ton compilo
est parfaitement capable de te dire si s a ete utilisee sans avoir ete
initialisee.
Apres, si tu es C99 ou plus, un style raisonnable consiste a ne declarer
les variables QUE au moment ou on va les initialiser. Le code precedent
devient
{
char *s = malloc(qqc);
if (s == NULL) {
...
}
...
}
ca ne s'applique pas au noyau d'Open (on a encore une archi sur laquelle
le seul compilo supporte est gcc 2.95... un compilo plus recent fait des
trucs invraisemblablement faux en termes d'optimisation).
(note que ce style est sujet a controverse pour les vieux, qui veulent
absolument declarer toutes les variables en tete de fonction)
Désolé, kern_sysctl.c était effectivement pas un très bon exemple.
Visiblement, tu es relativement debutant. Attaquer par le code d'un
noyau n'est pas du tout du tout un bon exemple.
Je te recommande de commencer par apprendre un peu le langage pour de vrai,
par exemple avec le K&R, avant de t'attaquer a des trucs plus complexes.
Cote "securite", de tels conseils sont relativement nocifs.
Les initialisations parasites peuvent donner l'illusion que le code
est propre, alors que des problemes plus sournois s'y cachent.
Pire: les initialisations en plus rajoutent "du bruit" en terme de code
qui au final ne sert pas (parce que ton compilo va bien evidemment
optimiser une double initialisation), et conduisent certaines personnes
a encapsuler leurs allocations dans des grosses macros qui font plein
de trucs et qui cassent tout.
La bonne securite s'obtient generalement en sachant ce qu'on fait, donc
commence par reellement apprendre le langage depuis les bases, puis en
essayant d'ecrire du code le plus clair possible, en evitant d'etre
"cute"...
Le code noyau, pour apprendre a ecrire du code C, c'est pas tip-top. Bon,
tu aurais pu faire pire et regarder le code noyau linux (qui est tellement
noye dans les spinlocks que plus rien n'est visible) ou le code GNU (qui
n'est a peu pres jamais ecrit en C sans au moins trois surcouches de
macros et d'indirections a la con)
K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
In article ,
JKB wrote:K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Plus serieusement, le code noyau n'est jamais du C standard, comme tout
code embarque qui se respecte.
C'est a peu pres le pire qu'on puisse imaginer pour apprendre le langage.
Vu les questions du posteurs de depart, il faudrait deja qu'il apprenne
a lire des paragraphes entiers, ou a preter un peu d'attention aux details
comme remarquer que le malloc() qu'il voit a 2 parametres de trop.
Il y a deja des trucs sournois dans du code userland, mais sur du code noyau,
entre les specificites de l'edition de liens (les variables ne sont pas
forcement initialisees comme en userland), les specificites du processeur
(cf les bugs de longsoon et des problemes de pipeline qui font que certaines
gardes anti pointeur nul peuvent finir en panic), j'en passe et des
meilleures, c'est pas avec ca qu'il va arriver a faire quelque chose d'a peu
pres rigoureux avec un langage qui, soyons franc, est hostile pour le
debutant.
(sans compter donc les trucs evidents a voir comme le fait qu'un noyau
est compile en free-standing, et donc que les fonctions-de-la-libc ne sont
pas les fonctions-de-la-libc-du-noyau, entre printf qui prend des chaines
de formats subtilement differentes, malloc qui n'a rien a voir, la gestion
memoire qui est tres differente, la possibilite de faire des trucs
totalement non portables avec les adresses memoires, les problemes d'endianess
qui pointent leur nez des qu'on met une carte graphique dans autre chose
qu'un intel, etc, etc)
In article <slrnkui4e6.imu.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.
Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Plus serieusement, le code noyau n'est jamais du C standard, comme tout
code embarque qui se respecte.
C'est a peu pres le pire qu'on puisse imaginer pour apprendre le langage.
Vu les questions du posteurs de depart, il faudrait deja qu'il apprenne
a lire des paragraphes entiers, ou a preter un peu d'attention aux details
comme remarquer que le malloc() qu'il voit a 2 parametres de trop.
Il y a deja des trucs sournois dans du code userland, mais sur du code noyau,
entre les specificites de l'edition de liens (les variables ne sont pas
forcement initialisees comme en userland), les specificites du processeur
(cf les bugs de longsoon et des problemes de pipeline qui font que certaines
gardes anti pointeur nul peuvent finir en panic), j'en passe et des
meilleures, c'est pas avec ca qu'il va arriver a faire quelque chose d'a peu
pres rigoureux avec un langage qui, soyons franc, est hostile pour le
debutant.
(sans compter donc les trucs evidents a voir comme le fait qu'un noyau
est compile en free-standing, et donc que les fonctions-de-la-libc ne sont
pas les fonctions-de-la-libc-du-noyau, entre printf qui prend des chaines
de formats subtilement differentes, malloc qui n'a rien a voir, la gestion
memoire qui est tres differente, la possibilite de faire des trucs
totalement non portables avec les adresses memoires, les problemes d'endianess
qui pointent leur nez des qu'on met une carte graphique dans autre chose
qu'un intel, etc, etc)
In article ,
JKB wrote:K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Plus serieusement, le code noyau n'est jamais du C standard, comme tout
code embarque qui se respecte.
C'est a peu pres le pire qu'on puisse imaginer pour apprendre le langage.
Vu les questions du posteurs de depart, il faudrait deja qu'il apprenne
a lire des paragraphes entiers, ou a preter un peu d'attention aux details
comme remarquer que le malloc() qu'il voit a 2 parametres de trop.
Il y a deja des trucs sournois dans du code userland, mais sur du code noyau,
entre les specificites de l'edition de liens (les variables ne sont pas
forcement initialisees comme en userland), les specificites du processeur
(cf les bugs de longsoon et des problemes de pipeline qui font que certaines
gardes anti pointeur nul peuvent finir en panic), j'en passe et des
meilleures, c'est pas avec ca qu'il va arriver a faire quelque chose d'a peu
pres rigoureux avec un langage qui, soyons franc, est hostile pour le
debutant.
(sans compter donc les trucs evidents a voir comme le fait qu'un noyau
est compile en free-standing, et donc que les fonctions-de-la-libc ne sont
pas les fonctions-de-la-libc-du-noyau, entre printf qui prend des chaines
de formats subtilement differentes, malloc qui n'a rien a voir, la gestion
memoire qui est tres differente, la possibilite de faire des trucs
totalement non portables avec les adresses memoires, les problemes d'endianess
qui pointent leur nez des qu'on met une carte graphique dans autre chose
qu'un intel, etc, etc)
Le Fri, 19 Jul 2013 10:26:30 +0000 (UTC),
Marc Espie écrivait :In article ,
JKB wrote:K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Alors tu vas me permettre de parler d'OpenBSD qui est cassé sur
Loongson et des locales assez mal supportées sur sparc/sparc64.
C'est tout de même plus récent et plus utilisé qu'un VAX sous
NetBSD.
Le Fri, 19 Jul 2013 10:26:30 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrnkui4e6.imu.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.
Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Alors tu vas me permettre de parler d'OpenBSD qui est cassé sur
Loongson et des locales assez mal supportées sur sparc/sparc64.
C'est tout de même plus récent et plus utilisé qu'un VAX sous
NetBSD.
Le Fri, 19 Jul 2013 10:26:30 +0000 (UTC),
Marc Espie écrivait :In article ,
JKB wrote:K&R _ansi_, je suppose que tu ne parlais pas de l'édition
originelle. Parce que si on rentre dans les subtilités des passages
d'arguments du C K&R, je pense que l'OP n'en a pas fini.
Oui, bien sur. Dans ma tete le C pre-ANSI est finalement mort.Je sens le troll arriver. Il est vrai qu'on est trolldi. Donc je
marche dedans en disant qu'il aurait pu mieux faire et regarder le
code noyau de NetBSD ;-)
Ah, Trolldi...
NetBSD, le systeme qui cross-compile tout au point que certains bouts
d'architecture sont totalement casses (confere la libm sur vax, avec
le code d'atan2f betement recopie de sinf, donc qui ne risque pas trop
de marcher vu qu'il y a un parametre de plus...)
Alors tu vas me permettre de parler d'OpenBSD qui est cassé sur
Loongson et des locales assez mal supportées sur sparc/sparc64.
C'est tout de même plus récent et plus utilisé qu'un VAX sous
NetBSD.
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent
vu que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL
afin de ne pas oublier de l’allouer plus tard dans le code.
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent
vu que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL
afin de ne pas oublier de l’allouer plus tard dans le code.
En fait en lisant qques livres (peut être trop scolaire) j'ai souvent
vu que les auteurs conseillaient de déclarer un pointeur puis de
l'initialiser à NULL
afin de ne pas oublier de l’allouer plus tard dans le code.
