Le 04 novembre 2018 à 07:21:30 godrik a écrit :
Le 03 novembre 2018 à 22:13:03 GouKen91 a écrit :
c11Bah c'est dangeeux de faire du C18. C'est trop recent, il y a plein de compilateur qui ne vont pas le supporter. Mais le C11 est sorti il y a belle lurette maintenant. Tous les compilateurs dignes de ce nom vont avoir le support qui va bien.
Pourquoi se faire chier avec un C antique?
Sans aller au C89, le C99 est bien mieux. 
Sinon,
Le 01 novembre 2018 à 23:58:06 [Hard]Ware a écrit :
Le 01 novembre 2018 à 14:08:20 GouKen91 a écrit :
Variables non initialisées.lesquelles ?
off_t off1;
off_t off2;
char *src;
char *dest;Certains includes inutiles.
Ah oui, c'est un mauvais copier/coller
Retour en plein milieu.
qu'est-ce que ça veut dire ?
des "return" en plein milieu. En général, c'est en fin de fonction.
Si tu essayes de faire du POSIX, et que tu return en plein milieu, c'est que le début de la fonction est mal écrit.
Pas de fonction.
Ouais, je vais au moins mettre la lecture des arguments en fonction.
Je pourrais aussi faire la lecture/écriture j'imagine.Pas d'utilisation de getopts.
Non, je connaissais pas ça.
Je regarderai pour une prochaine fois.Pas d'accolades ouvrants/fermantes de temps en temps.
Simplement pour les petits if ?
C'est plus une question de style qu'autre chose ça non ?
Question de goût en effet.
Des goto pas justifiés.
On m'a dit que c'était une pratique courante d'utiliser un goto pour ce genre de gestion d'erreur. Pourquoi pas ?
Qu'est-ce qui en justifierais sinon ?
Bof, on peut toujours s'en affranchir. T'en as encore dans le kernel, mais bon pour chaque nouveau patch ou nouveau support, c'est refusé direct.
Libération de mémoire sans tester le pointeur.
Le manuel spécifie que faire
free(NULL)n'est pas une erreur et que ça fait rien. Tu veux que je vérifie quoi, et que j'en fasse quoi ? Par ailleursvalgrindne me signale rien...
En fait, si tu test toi même le pointeur avant d'appeler la fonction free, tu gagnes de cycles. Et, c'est quand même mieux de tester avant d'utiliser ta variable. 
Fermeture de fd sans tester le fd.
Le fd ne va jamais changer tout seul ? Pourquoi le tester ? Et surtout comment ? Qu'est-ce qui peut se produire ?
T'en sais rien, open est un appel système, donc le fd est fourni/géré par le kernel. S'il le ferme, t'es baisé.
Si l'oom killer craque, t'es baisé également. 
J'te reçois en entretien, t'es pas pris.
Oui ben je passe pas un entretien là, je suis là pour apprendre
Sinon, recompile déjà avec -Wall -Wextra, ça permet de faire un premier nettoyage.
Je compile déjà avec :
gcc -std=c11 -Wall -Wconversion -Werror -Wextra -Wpedantic -c "%f" -pthread -fstack-protector-all
Effectivement, peut être pas de warnings à cause du c11.
Mais bon, quitte à prendre tous les défauts du C++, autant faire directement du C++
Le 12 novembre 2018 à 20:30:02 GouKen91 a écrit :
Le 04 novembre 2018 à 07:21:30 godrik a écrit :
Le 03 novembre 2018 à 22:13:03 GouKen91 a écrit :
c11Bah c'est dangeeux de faire du C18. C'est trop recent, il y a plein de compilateur qui ne vont pas le supporter. Mais le C11 est sorti il y a belle lurette maintenant. Tous les compilateurs dignes de ce nom vont avoir le support qui va bien.
Pourquoi se faire chier avec un C antique?Sans aller au C89, le C99 est bien mieux.
Pourquoi? Tu as l'air tres opposer au C11. Mais tu ne donnes aucun argument.
Retour en plein milieu.
qu'est-ce que ça veut dire ?
des "return" en plein milieu. En général, c'est en fin de fonction.
Si tu essayes de faire du POSIX, et que tu return en plein milieu, c'est que le début de la fonction est mal écrit.
C'est une question de style ca. Perso, je trouve qu'un return bien place en milieu de fonction, ca peut rendre le code beaucoup plus facil a lire dans certains cas. Apres il faut faire attention a ne pas leaker de memoire et companie bien sur. Mais dire que c'est mal ecrit, c'est juste faux.
Des goto pas justifiés.
On m'a dit que c'était une pratique courante d'utiliser un goto pour ce genre de gestion d'erreur. Pourquoi pas ?
Qu'est-ce qui en justifierais sinon ?Bof, on peut toujours s'en affranchir. T'en as encore dans le kernel, mais bon pour chaque nouveau patch ou nouveau support, c'est refusé direct.
Mais c'est pas du code pour le kernel qu'il ecrit. Le manuel de style du noyau n'est pas important. On peux s'affranchir du goto, mais quel est l'interet. Si le code est lisible et correcte. La seule raison de le reecrire est une question de style. Tu peux reecrire tout tes for en while si ca t'amuse. Mais c'est completement inutile.
Libération de mémoire sans tester le pointeur.
Le manuel spécifie que faire
free(NULL)n'est pas une erreur et que ça fait rien. Tu veux que je vérifie quoi, et que j'en fasse quoi ? Par ailleursvalgrindne me signale rien...En fait, si tu test toi même le pointeur avant d'appeler la fonction free, tu gagnes de cycles. Et, c'est quand même mieux de tester avant d'utiliser ta variable.
Pourquoi? Tu ne gagnes des cycles que dans el cas ou le pointeur est NULL. Mais c'est un cas extreme qui n'arrive pas en pratique. Et gagner trois cycle quand tu fais de l'IO, c'est pas important.
Le 12 novembre 2018 à 20:30:02 GouKen91 a écrit :
Le 04 novembre 2018 à 07:21:30 godrik a écrit :
Le 03 novembre 2018 à 22:13:03 GouKen91 a écrit :
c11Bah c'est dangeeux de faire du C18. C'est trop recent, il y a plein de compilateur qui ne vont pas le supporter. Mais le C11 est sorti il y a belle lurette maintenant. Tous les compilateurs dignes de ce nom vont avoir le support qui va bien.
Pourquoi se faire chier avec un C antique?Sans aller au C89, le C99 est bien mieux.
Quel est le problème avec le C11, au juste 
A ma connaissance, le C11ne fait qu'ajouter quelques fonctionnalités dans la bibliothèque standard (threading, opérations atomiques, nombres complexes, etc) et pour ce qui est du langage en lui même, à part la standardisation des attributs pour l'alignement des données, les struct et union anonymes et static_assert, le langage est identique à C99. La seule "incompatibilité", c'est que l'implémentation par le compilateur des VLA, qui était obligatoire en C99 est devenue optionnelle en C11.
Le 12 novembre 2018 à 20:39:42 GouKen91 a écrit :
Fermeture de fd sans tester le fd.
Le fd ne va jamais changer tout seul ? Pourquoi le tester ? Et surtout comment ? Qu'est-ce qui peut se produire ?
T'en sais rien, open est un appel système, donc le fd est fourni/géré par le kernel. S'il le ferme, t'es baisé.
Si l'oom killer craque, t'es baisé également.
Mais sa variable fd dans son programme ne va pas changer de valeur toute seule. Qu'est-ce qu'il est sensé tester ?
Et puis appeler close sur un descripteur invalide n'a aucun effet.
Le 14 novembre 2018 à 17:37:52 godrik a écrit :
Le 12 novembre 2018 à 20:30:02 GouKen91 a écrit :
Le 04 novembre 2018 à 07:21:30 godrik a écrit :
Le 03 novembre 2018 à 22:13:03 GouKen91 a écrit :
c11Bah c'est dangeeux de faire du C18. C'est trop recent, il y a plein de compilateur qui ne vont pas le supporter. Mais le C11 est sorti il y a belle lurette maintenant. Tous les compilateurs dignes de ce nom vont avoir le support qui va bien.
Pourquoi se faire chier avec un C antique?Sans aller au C89, le C99 est bien mieux.
Pourquoi? Tu as l'air tres opposer au C11. Mais tu ne donnes aucun argument.
C'est de la merde.
Plus sérieusement, toutes les features ne sont pas implémentées dans tous les compilateurs. Automatiquement, dans l'industrie, c'est ban direct. Ca me semble être une raison suffisante pour s'en affranchir et rester sur une version éprouvée.
Surtout que le mec qui sait développer, sait déjà se démerder avec les threads, l'alignement, sans devoir y foutre des macro immondes.
Le 14 novembre 2018 à 17:45:35 godrik a écrit :
Retour en plein milieu.
qu'est-ce que ça veut dire ?
des "return" en plein milieu. En général, c'est en fin de fonction.
Si tu essayes de faire du POSIX, et que tu return en plein milieu, c'est que le début de la fonction est mal écrit.C'est une question de style ca. Perso, je trouve qu'un return bien place en milieu de fonction, ca peut rendre le code beaucoup plus facil a lire dans certains cas. Apres il faut faire attention a ne pas leaker de memoire et companie bien sur. Mais dire que c'est mal ecrit, c'est juste faux.
Des goto pas justifiés.
On m'a dit que c'était une pratique courante d'utiliser un goto pour ce genre de gestion d'erreur. Pourquoi pas ?
Qu'est-ce qui en justifierais sinon ?Bof, on peut toujours s'en affranchir. T'en as encore dans le kernel, mais bon pour chaque nouveau patch ou nouveau support, c'est refusé direct.
Mais c'est pas du code pour le kernel qu'il ecrit. Le manuel de style du noyau n'est pas important. On peux s'affranchir du goto, mais quel est l'interet. Si le code est lisible et correcte. La seule raison de le reecrire est une question de style. Tu peux reecrire tout tes for en while si ca t'amuse. Mais c'est completement inutile.
Libération de mémoire sans tester le pointeur.
Le manuel spécifie que faire
free(NULL)n'est pas une erreur et que ça fait rien. Tu veux que je vérifie quoi, et que j'en fasse quoi ? Par ailleursvalgrindne me signale rien...En fait, si tu test toi même le pointeur avant d'appeler la fonction free, tu gagnes de cycles. Et, c'est quand même mieux de tester avant d'utiliser ta variable.
Pourquoi? Tu ne gagnes des cycles que dans el cas ou le pointeur est NULL. Mais c'est un cas extreme qui n'arrive pas en pratique. Et gagner trois cycle quand tu fais de l'IO, c'est pas important.
Pour les goto, t'as déjà débuggué en assembleur ?
Je pense que t'as jamais bossé dans l'industrie.
Ce que tu racontes là, c'est ban def direct si tu commences à faire du misra ou du safe c.
Mais sa variable fd dans son programme ne va pas changer de valeur toute seule. Qu'est-ce qu'il est sensé tester ?
Ca dépend de l'OS.
Sinon, j'ai bien compris qu'il faisait pas du code sécuritaire d'A380, mais ça n'empêche pas d'avoir tout de même de bonnes pratiques, relativement peu coûteuses.
Optionnelles je l'accorde, mais bon, en général on fait du C pour "maîtriser" au maximum. Quitte à vouloir en faire le moins possible, autant aller faire du Java et jouer avec le garbage collector 
Le 16 novembre 2018 à 20:27:21 GouKen91 a écrit :
Le 14 novembre 2018 à 17:37:52 godrik a écrit :
Le 12 novembre 2018 à 20:30:02 GouKen91 a écrit :
Le 04 novembre 2018 à 07:21:30 godrik a écrit :
Le 03 novembre 2018 à 22:13:03 GouKen91 a écrit :
c11Bah c'est dangeeux de faire du C18. C'est trop recent, il y a plein de compilateur qui ne vont pas le supporter. Mais le C11 est sorti il y a belle lurette maintenant. Tous les compilateurs dignes de ce nom vont avoir le support qui va bien.
Pourquoi se faire chier avec un C antique?Sans aller au C89, le C99 est bien mieux.
Pourquoi? Tu as l'air tres opposer au C11. Mais tu ne donnes aucun argument.
C'est de la merde.
Plus sérieusement, toutes les features ne sont pas implémentées dans tous les compilateurs. Automatiquement, dans l'industrie, c'est ban direct. Ca me semble être une raison suffisante pour s'en affranchir et rester sur une version éprouvée.
C'est un peu neuf, mais ils le seront eventuellement. Et tu peux tester a la compilation si les fonctionallites sont supporte et faire un defaut sur une autre implementation si il faut.
Surtout que le mec qui sait développer, sait déjà se démerder avec les threads, l'alignement, sans devoir y foutre des macro immondes.
Mais ce n'etait pas forcement standardise ces choses la. Les implementations de threads ne sont pas forcement portable par exemple entre les systeme unix et windows. Voir meme vers d'autres OS. Du coup avoir un standard integre dans le langage est une bonne chose.
Le 14 novembre 2018 à 17:45:35 godrik a écrit :
Retour en plein milieu.
qu'est-ce que ça veut dire ?
des "return" en plein milieu. En général, c'est en fin de fonction.
Si tu essayes de faire du POSIX, et que tu return en plein milieu, c'est que le début de la fonction est mal écrit.C'est une question de style ca. Perso, je trouve qu'un return bien place en milieu de fonction, ca peut rendre le code beaucoup plus facil a lire dans certains cas. Apres il faut faire attention a ne pas leaker de memoire et companie bien sur. Mais dire que c'est mal ecrit, c'est juste faux.
Des goto pas justifiés.
On m'a dit que c'était une pratique courante d'utiliser un goto pour ce genre de gestion d'erreur. Pourquoi pas ?
Qu'est-ce qui en justifierais sinon ?Bof, on peut toujours s'en affranchir. T'en as encore dans le kernel, mais bon pour chaque nouveau patch ou nouveau support, c'est refusé direct.
Mais c'est pas du code pour le kernel qu'il ecrit. Le manuel de style du noyau n'est pas important. On peux s'affranchir du goto, mais quel est l'interet. Si le code est lisible et correcte. La seule raison de le reecrire est une question de style. Tu peux reecrire tout tes for en while si ca t'amuse. Mais c'est completement inutile.
Libération de mémoire sans tester le pointeur.
Le manuel spécifie que faire
free(NULL)n'est pas une erreur et que ça fait rien. Tu veux que je vérifie quoi, et que j'en fasse quoi ? Par ailleursvalgrindne me signale rien...En fait, si tu test toi même le pointeur avant d'appeler la fonction free, tu gagnes de cycles. Et, c'est quand même mieux de tester avant d'utiliser ta variable.
Pourquoi? Tu ne gagnes des cycles que dans el cas ou le pointeur est NULL. Mais c'est un cas extreme qui n'arrive pas en pratique. Et gagner trois cycle quand tu fais de l'IO, c'est pas important.
Pour les goto, t'as déjà débuggué en assembleur ?
Ouais. Je fais de la performance dans la vie. Donc oui, je lis et corrige du code complique en assembleur assez regulierement. Quand tu tombe a ces niveaux la du systeme, il n'y a rien d'evident.
Je pense que t'as jamais bossé dans l'industrie.
Ce que tu racontes là, c'est ban def direct si tu commences à faire du misra ou du safe c.
Non, c'est vrai que je n'ecris pas de code pour l'industrie. Mais j'ecris du code qui tourne sur les plus grande machines du monde. Et quand tu ponds du code qui tourne sur 1 million de core. Et bah tu as interet a faire attention.
Les idees du type "tous les codes ecrits comme ca sont pourris" ne resistent pas au passage a la vrai vie ou tous les problemes sont compliques. En pratique les codes que je regardes sont ecris par des equipes mixtes avec des experts en domaine (physique souvent), en calcul scientifique (en general, des matheux), en systeme (en general des informaticiens). Les contraintes de style que les ecoles de pisseurs de code mettent, on s'en tape completement. Tant que le code est lisible et qu'il est facil de ce convaincre qu'il n'y a pas de bug, c'est ce qui est important, et si la facon claire pour l'equipe d'ecrire le code est de mettre un goto, ou de mettre un return au milieu de la fonction. Et bah c'est tres bien.
J'ai pas que ca a foutre de reecrire 300000 lignes de codes developpe dans les 40 dernieres annees parceque les styles sont moches.
Et bah c'est tres bien.
Ouais là en effet, je suis pas sûr qu’il faille continuer à essayer de débattre.
Ça marche donc c’est bon.
