Pour une fois, pas d'accord avec @Pierrot : pour moi, celui qui reçoit le pointeur a juste le droit de l'utiliser, pas question de free() la zone pointée. C'est au créateur de la zone --- celui qui a fait le malloc() ---- à se charger de libérer la mémoire qu'il a demandée.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Je vote pour edgarjacobs ! (Pierrot doit être un vieux bricolo... )
Mais je trouve que ces choses là devraient obligatoirement apparaître dans les commentaires. Je sais que les pros mettent peu de commentaires, seulement quand c'est vraiment indispensable, mais n'est-ce pas le cas ici ? Par exemple je ferais ce genre de chose :
void ft_strjoin(const char *s1, const char *s2, char *dest)
// Cette fonction concatène les chaînes 's1' et 's2' et stocke
// le résultat dans la zone pointée par 'dest'.
// La fonction ne vérifie pas que les zones pointées ont une taille
// suffisante, c'est au programme appelant de le faire.
// La fonction ne fait aucune allocation, c'est au programme
// appelant de le faire (et de faire les 'free').
{
/* ... ... ... ... */
}
@robun: >Je vote pour edgarjacobs ! (Pierrot doit être un vieux bricolo... Tu n'as pas tout à fait tort (pas tord ...) Mais quand on crée des noeuds pour des listes chaînées, est-ce que je dois retourner dans la fonction de création pour lui demander de libérer l'espace?
Le Tout est souvent plus grand que la somme de ses parties.
Car je n'utilise strlen qu'à l'interieur de mon strjoin, c'est spécifique à mon code, ce n'était d'ailleurs pas le cas dans la première version que j'ai envoyé. Le seul cas dans mon programme où s = NULL c'est au premier appel de la fonction, dans ce cas là je veux juste Malloc la taille de ma s2. j'aurais pu le mettre dans mon strjoin, c'est exactement ce que j'ai compris de la réponse d'avant.
Et ce que tu fais s'appelle de la programmation défensive. En gros : se protéger de ce que le développeur envoie en argument mais ce n'est pas à la fonction de changer de comportement en fonction d'erreur du développeur. Par exemple, strlen ne vérifie pas si la chaine passée en entrée est NULL car ça n'a pas de sens.
Ce n'est pas à une fonction de supprimer / libérer les ressources de ses arguments car elle ne sait pas comment cela est géré. Il n'y a pas que malloc qu'on peut utiliser pour allouer des données par exemple, certains développeur veulent utiliser leur propre technologies (sans parler de variables statiques, constantes, etc)
De rares cas peuvent être tolérés afin de rendre le code moins verbeux. C'est par exemple le cas de free qui accepte explicitement un pointeur nul. On peut aussi citer des fonctions comme dans la bibliothèque jansson qui accepte des pointeurs nul dans json_is_object parce que si c'est NULL, on peut effectivement considérer que c'est clairement pas un objet JSON.
Pour le reste, faisons le code le plus simple et si ça ne marche pas : PEBKAC.
- Edité par markand 20 décembre 2022 à 9:24:11
git is great because Linus did it, mercurial is better because he didn't.
> Je sais que les pros mettent peu de commentaires, seulement quand c'est vraiment indispensable,
De nos jours, les programmeurs sérieux ont arrêté de se la péter dans le genre "le code suffit pour comprendre" (et si vous ne comprenez pas mon code, c'est que vous êtes trop nuls) (*). En particulier parce qu'on n'a pas forcément envie (et/ou que ça à foutre) de lire le code pour le comprendre, quand ce qu'on veut c'est retrouver l'ordre, le type et la signification des paramètres. C'est pratique quand l'ide vous le rappelle, par exemple.
Il y a des normes pour les commentaires, par exemple doxygen
/**
* \fn void str_concat(char *dst, const char *src1, const char *src2)
* \brief Place la concaténation de deux chaînes dans un tampon.
*
* \param dst adresse où placer le résultat
* \param src1 première chaîne
* \param src2 seconde chaîne
*
* Le pointeur dst doit désigner un emplacement de taille suffisante,
* c'est à dire au moins strlen(src1) + strlen(src2) + 1 octets.
**/
void str_concat(char *dst, const char *src1, const char *src2)
{
while (*src1) *dst++ = *src1++;
while (*src2) *dst++ = *src2++;
*dst = '\0';
}
(*) en fait c'est souvent que le type qui dit ça est incapable de rédiger pour expliquer clairement un truc pas évident qu'il a pondu, ce qui n'est pas tout à fait un point positif quand il s'agit de bosser à plusieurs. Pas très pro...
------------
> free et NULL
En fait, c'est cohérent avec malloc/realloc qui peutretourner un pointeur NULL quand on lui demande une taille = 0.
DESCRIPTION The malloc() function allocates size bytes and returns a pointer to the allocated memory. The memory is not initialized. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free().
The free() function frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc(), or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behavior occurs. If ptr is NULL, no operation is performed.
-----
PS sur le commentaires : il faut bien préciser; à l'attention des débutants : que quand ils lisent
int i; // on déclare une variable entière nommée i
i = 0; // on initialise i à 0
...
i++; // on ajoute 1 à i
c'est normalement dans le contexte pédagogique d'un document destiné à leur enseignerleséléments de base du langage de programmation.
Dans du code normal, ce genre de trucs,
c'est carrément insultant pour celui qui le lira (on suppose qu'il ne connaît pas les bases du langage, donc qu'il est incompétent)
ça lui fait perdre son temps donc il ne regardera plus les commentaires
et ça lui fera louper ceux qui sont éventuellement pertinents.
- Edité par michelbillaud 20 décembre 2022 à 13:51:57
> Je sais que les pros mettent peu de commentaires, seulement quand c'est vraiment indispensable,
De nos jours, les programmeurs sérieux ont arrêté de se la péter dans le genre "le code suffit pour comprendre" (et si vous ne comprenez pas mon code, c'est que vous êtes trop nuls) (*). En particulier parce qu'on n'a pas forcément envie (et/ou que ça à foutre) de lire le code pour le comprendre, quand ce qu'on veut c'est retrouver l'ordre, le type et la signification des paramètres. C'est pratique quand l'ide vous le rappelle, par exemple.
[...]
(*) en fait c'est souvent que le type qui dit ça est incapable de rédiger pour expliquer clairement un truc pas évident qu'il a pondu, ce qui n'est pas tout à fait un point positif quand il s'agit de bosser à plusieurs. Pas très pro...
[...]
-
Edité par michelbillaud il y a 9 minutes
Il y a une différence fondamentale entre documenter l'API (l'exemple que tu nous montre) et documenter le code. Le code doit être lisible et compréhensible sans commentaires (ou avec un minimum proche de 0).
Si on se retrouve à devoir documenter le code pour qu'un autre dèv puisse le comprendre c'est que le code produit n'est pas lisible, cela signifie qu'on écrit du code avec ses pieds, qu'en général on nomme mal les choses, on sépare mal les responsabilités, on a produit un design de merde, etc.
White Crow : les commentaires sont venus sur le tapis parce que je parlais de mettre des commentaires pour expliquer que la fonction ne s'occupe pas des 'malloc' et des 'free' ni de vérifier que la place est disponible, et je trouvais que c'est le genre de commentaire indispensable pour, par exemple, le programme de BUFFER_SIZE (c'était le sujet de la discussion depuis la fin de 1ère page). C'est bien ce genre de commentaire que tu placerais dans la documentation de l'API ?
Si il arrive qu'une fonction fasse un free sur des paramètres qu'on lui a refilés, c'est pas du luxe que ça soit dans la description du rôle de la fonction .
Pour les commentaires du code ça dépend. Y en a qui reposent sur de la théorie plus ou moins "lourde" qui ne se réinvente pas facilement en lisant le code, c'est pas inutile de mentionner d'où ça sort.
La somme des éléments d'un tableau, y a pas trop besoin.
- Edité par michelbillaud 20 décembre 2022 à 13:52:31
White Crow : les commentaires sont venus sur le tapis parce que je parlais de mettre des commentaires pour expliquer que la fonction ne s'occupe pas des 'malloc' et des 'free' ni de vérifier que la place est disponible, et je trouvais que c'est le genre de commentaire indispensable pour, par exemple, le programme de BUFFER_SIZE (c'était le sujet de la discussion depuis la fin de 1ère page). C'est bien ce genre de commentaire que tu placerais dans la documentation de l'API ?
Si tu documentes une API c'est pour celui qui va utiliser «le code» que tu développes ; cela peut être toi, toi dans 6 mois, un autre, etc. L'API documente réellement ce que l'utilisateur doit savoir pour bien utiliser «tes fonctions», rien de plus, rien de moins. Ici être le précis possible est souvent préférable car ce sera souvent le reflet d'uns specification, la base d'un manuel et une ligne conductrice pour écrire des tests. Utiliser un outil qui produit cette documentation via des tags dans le code, pourquoi pas. Cela permet de garder une certaine localité qui peut faciliter la maintenance de la documentation. Ce qui est important ici c'est qu'on parle de documentation.
Ensuite il y a les commentaires dans le code qui, par mon expérience, sont plus souvent du bruit inutile qu'une indication nécessaire. Cela est du bruit dangereux car il peuvent indiquer le contraire de ce qui est fait par oubli de mise à jour du commentaire après modification du code. Cela est du bruit car ils interrompent la lecture du code. Parfois ils indiquent un mauvais design comme un commentaire qui explique ce que fait un bloc d'instructions qui suit, puis on retombe sur un autre commentaire qui explique un bloc d'instructions etc. Cela montre qu'il faut simplement scinder le code en plusieurs fonctions, qui en les nommant adéquatement rendent tout commentaire inutile. Là je parle de commenter le code pour le rendre compréhensible et je ne parle plus de documentation.
Ensuite je suis Michel quand il parle d'extrait de code commenté pour les grands débutants … même si j'y mettrais tout de même un petit bémol, dans le sens que ça doit être réservé uniquement aux grands débutants. Dans les livres il est plus approprié (àmha) d'annoter hors code que de commenter le code.
Mais oui, que l'API soit ou non bien designée, qu'elle soit ou non cohérente, il est important de la documenter. On ne balance pas une boîte à outil sans un minimum de doc.
Mais là aussi il faut faire une toute petite remarque. Une API n'a vraiment de sens que dans le cadre du développement d'une bibliothèque. (qu'elle soit une bibliothèque généraliste ou de convenance). Le PO doit développer une telle bibliothèque dans le cadre de la piscine XLII. Il est donc nécessaire, au strict minimum, qu'il adhère aux specs (qui sont ce qu'elles sont), qu'il documente (et non commente) les outils qu'il met à disposition.
les commentaires qui font partie du code (pour aider à sa compréhension)
les annotations pour parler du code
comme dans
le problème c'est que c'est bien moins fatigant de tout foutre en vrac dans le source.
Par curiosité j'ai jeté un oeil dans l'antique et non moins vénérable K & R : il évite ce travers. Le source est commenté, mais pas de blabla
même si ça n'échappe pas à des complications inutiles : pourquoi combiner affectation et comparaison alors que
sign = n;
if (n < 0)
n = -n;
fait aussi bien l'affaire ?
et que le commentaire est trompeur : sign ne contient pas le signe, mais la valeur d'origine de l'entier à convertir. Et n pourrait s'appeler abs.
et que du coup on s'emmêlerait moins en démarrant sur
void itoa(int n, char s[])
{
int a; /* valeur absolue de n */
a = n;
if (a < 0)
a = -a;
...
Enfin bon, il s'agit ici de montrer un exemple de do-while : on voit bien que le code n'est pas là pour bavarder à propos de cette structure de contrôle.
White Crow : merci pour les précisions, je comprends mieux pourquoi tu parles de documentation : ce n'est pas la même chose qu'un commentaire.
Mais tu dis que la documentation d'une API sert aux utilisateurs. Et ceux qui maintiennent les fonctions ? N'ont-ils pas besoin d'un peu plus de commentaires que les utilisateurs ? Est-ce qu'on ne pourrait pas dire que la documentation est pour les utilisateurs, et les commentaires sont pour les mainteneurs ?
static int fat_ioctl_set_attributes(struct file *file, u32 __user *user_attr)
{
struct inode *inode = file_inode(file);
struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
int is_dir = S_ISDIR(inode->i_mode);
u32 attr, oldattr;
struct iattr ia;
int err;
err = get_user(attr, user_attr);
if (err)
goto out;
err = mnt_want_write_file(file);
if (err)
goto out;
inode_lock(inode);
/*
* ATTR_VOLUME and ATTR_DIR cannot be changed; this also
* prevents the user from turning us into a VFAT
* longname entry. Also, we obviously can't set
* any of the NTFS attributes in the high 24 bits.
*/
attr &= 0xff & ~(ATTR_VOLUME | ATTR_DIR);
/* Merge in ATTR_VOLUME and ATTR_DIR */
attr |= (MSDOS_I(inode)->i_attrs & ATTR_VOLUME) |
(is_dir ? ATTR_DIR : 0);
oldattr = fat_make_attrs(inode);
/* Equivalent to a chmod() */
ia.ia_valid = ATTR_MODE | ATTR_CTIME;
ia.ia_ctime = current_time(inode);
if (is_dir)
ia.ia_mode = fat_make_mode(sbi, attr, S_IRWXUGO);
else {
ia.ia_mode = fat_make_mode(sbi, attr,
S_IRUGO | S_IWUGO | (inode->i_mode & S_IXUGO));
}
/* The root directory has no attributes */
if (inode->i_ino == MSDOS_ROOT_INO && attr != ATTR_DIR) {
err = -EINVAL;
goto out_unlock_inode;
}
if (sbi->options.sys_immutable &&
((attr | oldattr) & ATTR_SYS) &&
!capable(CAP_LINUX_IMMUTABLE)) {
err = -EPERM;
goto out_unlock_inode;
}
/*
* The security check is questionable... We single
* out the RO attribute for checking by the security
* module, just because it maps to a file mode.
*/
err = security_inode_setattr(file_mnt_user_ns(file),
file->f_path.dentry, &ia);
if (err)
goto out_unlock_inode;
/* This MUST be done before doing anything irreversible... */
err = fat_setattr(file_mnt_user_ns(file), file->f_path.dentry, &ia);
if (err)
goto out_unlock_inode;
fsnotify_change(file->f_path.dentry, ia.ia_valid);
if (sbi->options.sys_immutable) {
if (attr & ATTR_SYS)
inode->i_flags |= S_IMMUTABLE;
else
inode->i_flags &= ~S_IMMUTABLE;
}
fat_save_attrs(inode, attr);
mark_inode_dirty(inode);
out_unlock_inode:
inode_unlock(inode);
mnt_drop_write_file(file);
out:
return err;
}
White Crow : merci pour les précisions, je comprends mieux pourquoi tu parles de documentation : ce n'est pas la même chose qu'un commentaire.
Mais tu dis que la documentation d'une API sert aux utilisateurs. Et ceux qui maintiennent les fonctions ? N'ont-ils pas besoin d'un peu plus de commentaires que les utilisateurs ? Est-ce qu'on ne pourrait pas dire que la documentation est pour les utilisateurs, et les commentaires sont pour les mainteneurs ?
En effet c'est une bonne question.
La qualité d'un code, du moins à mon avis, se mesure à sa lisibilité. La lisibilité est évidemment un critère très subjectif. C'est également une caractéristique que l'on peut sacrifier sur de nombreux autels comme celui de la performance, ou celui de la fainéantise ou encore celui «d'un idiome commun à tous les participants d'un projet».
Le principal problème des commentaires est qu'ils ne s'adressent uniquement à ceux qui les lisent, et le principal acteur qui ne les lit pas est le compilateur. Un changement dans une partie du programme peut influer sur des commentaires ailleurs dans le code. Par exemple, dans l'extrait que nous exhibe Michel que se passe-t-il si le comportement de security_inode_setattr change ? que reste-t-il de la validité du commentaire dans la fonction fat_ioctl_set_attributes aux lignes 54/58 ? Est-ce que ce commentaire sera toujours pertinent par la suite ? est-ce que ce commentaire ne produira pas l'effet inverse de ce qui était voulu, à savoir prévenir le mainteneur d'un comportement particulier qui lorsqu'il n'a plus lieu d'être continuera à provoquer des tests inutiles ?
OK, cela fait beaucoup de si … néanmoins rien n'interdit ce genre d'événement de se produire.
Dans le cas exhibé par Michel, il s'agit d'un contexte où l'on privilégie largement les performances à la lisibilité et même à la sécurité. Maintenant, pour une équipe qui connaît l'interface, les commentaires seront sans doute superflus, en revanche pour une personne qui rentre dans le code, ils ne le seront pas forcément. Pas forcément dans le sens que tant qu'ils sont valides (et aucune garantie n'est donnée) cela permet de s'affranchir de sortir du code et de lire la doc … Ici nous avons donc deux autels : la performance et la fainéantise.
Si l'on désire réellement disposer d'un code maintenable, on préférera la lisibilité à la performance, dans une grande mesure. Cela signifie la plupart du temps d'adapter le code au domaine auquel il s'applique. Dans le code exhibé par Michel par exemple, il semble qu'il n'y ait aucun besoin de commenter les lignes 3-17. Bon les lignes 3-8 indiquent une volonté de rester scotché à C89 … Mais les lignes 10-17 sont très claires, il suffit de lire pour les comprendre car le nommage est simple et l'idiome est cleui du kernel. Que peut bien faire un get_user à part récupérer un utilisateur? Que peut bien faire un mnt_want_write_file à part vouloir avoir un accès en écriture sur le point de montage (et si tu trifouilles ce code c'est que tu a une petite idée de ce que le driver fait et manipule) ? Que peut bien faire un inode_lock à part vérouiller un inode ?
C'est clair que les choses se compliquent en 19-52 ; mais le commentaire aurait-il été nécessaire si on refactorait pour ne faire qu'un appel de fonction ? idem pour la partie 54-75 … Bien nommé le besoin de commentaires s'évanouit presque à chaque fois. Mais un appel de fonction peut être coûteux … au point de vouloir plus payer le prix de bugs difficiles à débusquer meme au prix d'une sécurité moins élevée …
Donc, et c'est un avis très personnel, soit le code est lisible, sachant que lisible ne signifie pas «pas besoin d'avoir de connaissances sur le fonctionnement ou le design du code», et la maintenance est aisée parfois au prix d'une performance dégradée par rapport à une code moins lisible, plus facilement bugué et buguable.
Le commentaire des lignes 19-23 concerne le lien entre le code et le problème.
Le code masque deux attributs - un programmeur le comprend en le lisant, le commentaire explique POURQUOI on a fait ce choix (une histoire d'incompatibilité avec vfat et ntfs) ce qui ne se déduit pas des instructions C.
- Edité par michelbillaud 21 décembre 2022 à 9:38:41
Alors pourquoi ne pas refactorer cette portion de code en fonction ? C'est une occasion en or … des fois que le comportement change, on aura pas l'occasion d'oublier les portions éparses qui dépendent de ce comportement ; et si le comportement ne change pas, le fait d'voir une fonction rendra le code plus lisible sans avoir besoin de recourir à un commentaire.
Comme juste après … puisque c'est équivalent à un chmod pourquoi ne pas appeler chmod ?
etc.
Il y a sans doutes de «bonnes» raisons ; certainement une question de performance, mais ici on sacrifie lisibilité et sécurité au profit de cette performance. Et à la limite ce n'est pas étonnant dans un contexte de dév de driver. D'ailleurs le fait que ce soit un extrait de driver du kernel n'est apparemment pas un indicateur que le code soit de bonne qualité …
8) Commenting
Comments are good, but there is also a danger of over-
commenting. NEVER try to explain HOW your code works in
a comment: it’s much better to write the code so that
the working is obvious, and it’s a waste of time to
explain badly written code.
Generally, you want your comments to tell WHAT your code
does, not HOW. Also, try to avoid putting comments
inside a function body: if the function is so complex
that you need to separately comment parts of it, you
should probably go back to chapter 6 for a while. You
can make small comments to note or warn about something
particularly clever (or ugly), but try to avoid excess.
Instead, put the comments at the head of the function,
telling people what it does, and possibly WHY it does
it.
> D'ailleurs le fait que ce soit un extrait de driver du kernel n'est apparemment pas un indicateur que le code soit de bonne qualité …
Un driver de kernel Linux, c'est public, et ça a été relu. Même qu'il y en a qui couinent quand c'est trop mauvais :-)
Bon, alors montre-nous un dépôt avec plein plein de code C d'excellente qualité, ça nous fera des exemples concrets plutot que de parler dans le vague.
- Edité par michelbillaud 21 décembre 2022 à 19:40:47
> D'ailleurs le fait que ce soit un extrait de driver du kernel n'est apparemment pas un indicateur que le code soit de bonne qualité …
Un driver de kernel Linux, c'est public, et ça a été relu. Même qu'il y en a qui couinent quand c'est trop mauvais :-)
[...]
Bah oui … c'est aussi pour cela qu'il y a des recommendations comme celles dont j'ai fournit le lien
michelbillaud a écrit:
[...]
Bon, alors montre-nous un dépôt avec plein plein de code C d'excellente qualité, ça nous fera des exemples concrets plutot que de parler dans le vague.
- Edité par michelbillaud il y a environ 1 heure
Qui parle de code C irréprochable ? Quel que soit le projet un peu conséquent, il y aura toujours des couacs. Mais tu te rends compte tout de même que le problème tient plus dans le fait que tu puisses dire des choses concernant la documentation et l'assimiler aux commentaires. Les commentaires sont un moyen d'écrire des choses ignorées par le compilateur. Un commentaire peut se désynchroniser du code qu'il est sensé éclairer. Rien ne pourra jamais vérifier l'exactitude d'un commentaire, et surtout jamais le valider. Cela vaut évidemment aussi lorsque les commentaires sont utilisés pour la documentation.
Enfin je suppose que tu pourras nous montrer un exemple concret hors XLII et hors initiation à la programmation (et je ne parle toujours pas de C) qui impose de commenter le code.
- Edité par michelbillaud il y a environ 15 heures
En effet, tu as raison, peu importe le code exhibé … c'est un peu comme chercher sur internet un sujet et cherry picker ce qui est arrangeant.
La conclusion que l'on peut en tirer est certainement la conclusion à laquelle parviennent tous les dèv à un moment donné de leur vie : les commentaires ça ne sert pratiquement jamais à rien, et là le «pratiquement» se réduit à une peau de chagrin de l'épaisseur d'un électron.
Mais là j'exagère, les commentaires in-code permettent surtout de repérer un code qui sera soit à refactorer soit imposera une réorganisation profonde d'un API (par exemple). Les commentaires hors-code importent peu soit parce qu'il s'agit de headers lourd pour expliquer des choses que l'on retrouvera ou dans la doc ou dans un gestionnaire de projet ou dans un gestionnaire de source. L'utilisation des commentaires pour faire une doc … pourquoi pas, il y a au moins l'avantage de la localité mais là on utilise le mécanisme de commentaire dans un tout autre but, celui d'utiliser un outil externe.
Bon enfin l'objectif, c'était d'inciter l'OP à essayer de formuler le rôle exact de ses fonctions. Que ça ne fasse pas des libérations en douce sans l'avoir annoncé officiellement.
C'est là normalement qu'il devrait se rendre compte que c'est plus simple si on choisit de faire une chose à la fois.
En gros … soit rendre son code lisible (facile) soit ne pas commenter le commentaire écrit dans un langage formel ^_^ un vrai ouroboros.
Mais à nouveau, ne confondons pas commentaire et documentation, ni commentaire et spécification. Comme je le disais les commentaires «libres» peuvent avoir leur utilité surtout s'il ne sont pas utilisés pour se substituer à de la documentation, à de la spécification.
Certains outils peuvent trouver de l'information dans des commentaires, mais ce ne seront plus des commentaires, juste des morceaux de code ignorés par le compilateur.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
git is great because Linus did it, mercurial is better because he didn't.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C