lasher a écrit 2738 commentaires

À toi de rendre ton environnement idiot proof.

Je vais citer Rick Cook:

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.

Même chose avec les utilisateurs/sysadmin. Il y aura toujours un « meilleur » idiot. Ça ne justifie pas qu'on crache sur les utilisateurs pour autant hein. Juste que admin système ne veut pas dire uniquement jouer avec les machines, mais aussi joue… Euh, interagir avec les utilisateurs. :-)

Indéfini (Undefined Behavior) ou implementation defined ?

Ah oui, j'oubliais : je parlais de la dernière fonction (je n'avais pas testé les autres).

Si, complètement. clang et icc me le disent sans activer de warnings. gcc a besoin de -Wall.

Concernant la fonction et le commentaire, comme p1 et p2 sont de type const void*, écrire *p1 et *p2 n'a pas réellement de sens. Si la fonction de comparaison avait du renvoyer "juste" les valeurs -1, 0, et 1, alors il aurait même été complètement redondant pour les premières versions que je proposais de mon code. Le "truc" de ces fonctions de comparaisons est que la seule valeur "précise" à laquelle on s’intéresse est celle d’égalité (0). Dans la vraie vie, mon commentaire aurait sans doute été plus long, pour expliquer les entrées, vers quel type elles allaient être converties, etc. Là, c’était juste pour insister sur le fait que d'autres valeurs de retour, positives ou négatives et autres que -1 ou 1, étaient valides.

En règle générale, lorsque je compile du C avec gcc, je le fais avec -Wall -Wextra et même parfois (souvent) -pedantic. Je ne sais pas quelle est la règle officielle dans la norme, mais je sais que pour main, beaucoup (la plupart ?) des compilateurs retournent implicitement 0 si aucun return n'est inséré. clang m'indique que la fonction ne renvoie rien malgré son type de retour, et ceci sans warnings.icc tout pareil. Mea culpa, je n'avais pas testé mes codes avant de les poster ici.

Concernant tes autres questions (pourquoi passer des const void* plutôt que directement les int par valeur, etc.), zul et fearan ont parfaitement répondu : il s'agit d'un comparateur destiné à être passé à une fonction "générique". Seul void* correspond au type "générique" (sans passer par des macros).

C'est exactement qsort que je visais (j'ai eu le cas qui se posait récemment).

Oui bon, dans le dernier exemple, je suis allé un peu trop vite (comme quoi le copier-coller c'est mal), et évidemment, la bonne tête de la fonction devrait être :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p2.*/
int intcmp0(const void* p1, const void* p2) 
{
    return *(int*)p1 - *(int*)p2;
}

Cela dit, toutes mes erreurs sont attrapées par le compilateur, du coup je me sens pas trop trop merdeux. :-P
(J'ai même corrigé le commentaire, t'as vu).

La concision dans n'importe quel langage peut se révéler illisible. Je ne connais pas zsh (je ne le pratique pas du tout), donc en effet la ligne que tu fournis m'est hermétique. Pourtant, avant de me dire que franchement, quel est l'idiot qui a écrit la ligne ainsi, je me poserais la question de ce que la ligne fait, et oui, je passerais le temps à essayer de comprendre avant d'émettre une opinion.

Évidemment, en Perl je peux me passer d'utiliser use warnings; use strict;, de même qu'en C je peux écrire un truc du genre

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    return *(int*)p1 < *(int*)p2 ? -1 : 
           *(int*)p1 > *(int*)p2 ?  1 :
           0;
}

… qui, malgré l'alignement, est franchement difficile à lire. Ou bien, je peux écrire la même fonction ainsi :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    int i1 = *(int*)p1,
        i2 = *(int*)p2;
    return i1 < i2 ? -1 : 
           i1 > i2 ?  1 :
           0;
}

… Qui est déjà plus lisible.

Bien entendu, pour faire encore plus lisible, il serait sans doute mieux d'écrire ceci :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    int i1     = *(int*)p1,
        i2     = *(int*)p2,
        retval;

    if      (i1 < i2) retval = -1;
    else if (i1 > i2) retval =  1;
    else              retval =  0;
}

Mais au final, la version qui pour moi est la plus lisible et efficace est celle-ci :

/* Returns a value <0 if p1<p2, >0 if p1>p2, and 0 if p1=p1.*/
int intcmp(const void* p1, const void* p2) 
{
    return *(int*)i1 - *(*int*)i2;
}

… Et ça vient, entre autres, de la concision de l'écriture (moins de choses à lire = moins de choses à comprendre).

Évidemment je suis d'accord avec toi pour dire que la concision juste pour la concision est une mauvaise chose¹. Je n'ai aucun problème avec la critique d'un langage (il y a plein de choses à critiquer en Perl, en C, en bash, sans doute en zsh etc.). Mais ta phrase impliquait une généralité sur Perl (et zsh, mais je n'ai pas répondu car je ne connais pas ce shell), ce qui m'a effectivement fait réagir.

[1] et le code que j'ai écris en C comme en Perl dans mon message précédent n'a pas été écrit pour faire « plus joli » ou pour forcer le trait que Perl est lisible : je code à peu près comme ça en Perl.

Es-tu d'accord que des employés de n'importe quelle boite pourraient décider d'aller bosser ailleurs parce qu'ils estiment que leur chef direct est un gros beauf sexiste ? Si oui, il faut considérer les choses comme ceci : un grand nombre d'employés de Mozilla ont fait comprendre qu'il était hors de question pour eux de bosser pour un mec dont les idées allaient « éclabousser » l'image de leur employeur, mais qui en plus ont une différence d'opinion fondamentale sur certains sujets. Et du coup, ils le font savoir : c'est eux, ou lui. S'il était resté, je pense qu'une partie de ces gens auraient dégagé vers d'autres horizons.

Dans les deux cas, il s'agit de liberté : d'opinion, puis d'action.

[maclag] Donc Intel a fait de mauvais processeurs avec des grosses fréquences uniquement pour vendre une supériorité mesurée en GHz.

Pour un académique peut-être. Maintenant, regardons objectivement les choses : même "mauvaise", l'architecture netburst a duré un bon bout de temps, a gentiment augmenté en performances jusqu'à fournir, c'est vrai de petits hauts fourneaux miniature. Maintenant, chez AMD, ils n'ont jamais réussi à avoir un truc qui soit significativement mieux niveau perf. Ca a fait le job, comme on dit.

Ça c'est faux. Au contraire, pour un « académique », le P4 était super bon pour ce qui fait bander les fans d'optimisation de code réguliers : les instructions SSE du P4, et le pipeline allant jusqu'à 33 étages étaient du pain béni pour les applications extrêmement régulières en termes d'accès aux données et avec peu de branchements.

Par contre, pour l'informatique grand public / de gestion, les Athlon XP étaient beaucoup moins chers, et en plus offraient des performances comparables, voire meilleures qu'un P4 de fréquence « équivalente ». Il n'est pas très compliqué de comprendre pourquoi : si le P4 se trompe sur la prédiction de branchement, il doit flusher le pipeline, ce qui implique une pénalité allant jusqu'à 33 cycles. Sur un pipeline plus court (comme ceux d'AMD, qui avaient 12 ou 13 étages), tu as mécaniquement une pénalité moindre. D'ailleurs, la première chose qu'a faite Intel lorsqu'ils ont commencé à travailler sur la micro-architecture du Intel Core, ça a été de ressortir la micro-architecture du Pentium III, et de repartir de là.

Je vois pas ce que ca a de choquant tant qu'il le fait pas au nom de la boite. Il a quand même le droit de voter pour qui il veut ce brave homme non ?

Il ne s'agit pas d'un vote (qui dans des élections serait bien entendu anonyme), mais d'un don fait non seulement avec son nom, mais (comme je l'ai expliqué ailleurs) aussi en apposant le nom de son employeur (comme requis par la loi californienne).

[Concernant l'image de marque] C'est la politique de la boite, pas la sienne. Son boulot a lui comme a tous les salariés, c'est de gérer au mieux la boite.

La fonction de CEO/PDG c'est d'être la « face » de la boite dont tu es à la tête. Ensuite, tu oublies que les employés de Mozilla qui se sont rebellés l'ont fait car une partie est homosexuelle et craint (à juste titre) une possibilité de discrimination contre eux, justement parce qu'il a clairement annoncé ses opinions sur le sujet. Ensuite, il ne faut pas oublier que beaucoup d'employés de Mozilla vivent aux USA, le pays qui vient de passer une loi au Mississipi (et qui a presque réussi à passer la même en Arizona) sur la « liberté de religion » qui autorise les employeurs à refuser que l'assurance maladie qu'ils paient pour leurs employés lorsqu'il s'agit de pilule, car ça va à l'encontre de leurs convictions religieuses.

Donc en plus des problèmes posés par les convictions personnelles mais affichées publiquement par le PDG d'une boite pour l'image de marque d'icelle, il faut à cela rajouter les problèmes potentiels de discrimination qui pourraient survenir pour les employés.

En Californie, la loi impose que tu indiques qui est ton employeur lorsque tu fais un don. Du coup, la fondation a été (indirectement) impliquée, malgré elle. Et donc, lorsque le mec devient PDG de celle-ci, il traîne ses opinions et convictions publiques avec lui, et qu'il le veuille ou non, les associe à celles de son employeur.

Et moi je te dis que c'est idiomatique. Et citer Perl n'est pas forcément une bonne façon de donner du crédit à ton opinion : les gens que j'ai vus critiquer ce langage font partie (la plupart du temps) de ceux qui voudraient que Perl s'écrive comme du C, sans tenir compte — tadaaaa ! — des idiomes propres au langage. Si j'écris

#!/usr/bin/perl
use strict;
use warnings;
use Carp qw/croak/;

croak "USAGE: $0 <filename>" unless (@ARGV);

open (my $fh, '<', $filename) or die "Couldn't open $filename: $!";
my $file_content;
{
    local $/;
    $file_content = <$fh>;
}

do_something_with($file_content);

… Oui, j'estime que $/ et $! font partie des variables de Perl à connaître. De même qu'en C, si j'écris :

#define fatal(...) do {            \
    fprintf(stderr,__VA_ARGS__);   \
    if (errno != 0) perror(errno); \
    exit(errno);                   \
} while(0)

static inline void do_something_with(char* string, off_t sz) {
    string[sz-1] = '\0';
    puts(string);
}

int 
main(int argc, char ** argv)
{
    if (argc != 2) 
        fatal("USAGE: %s <filename>",argv[0]);

    char *filename = argv[1];

    int fd = open(filename,O_RDONLY);
    if (fd == -1) 
        fatal("Couldn't open %s",filename);

    struct stat file_info;
    fstat(fd,&file_info);
    off_t sz = file_info.st_size;

    char *file_content = malloc(sz);
    if (file_content == NULL)
        fatal("Couldn't allocate string of size %lu",sz);

    int nbytes = 0;
    do {
        nbytes = read(fd, file_content, sz);
    } while (nbytes == -1 && errno == EINTR);
    if (nbytes == -1)
        fatal("Couldn't read %lu bytes from %s\n", sz, filename);

    do_something_with(file_content,sz);

    free(file_content);

    return 0;
}

J'estime que le lecteur doit savoir ce que malloc signifie, qu'il sait faire un man fstat s'il n'a jamais rencontré la fonction en question (de même que pour un programme Perl on appellerait perldoc -f *fonction* ou perldoc -q *expression*), etc. Si je voyais ce code pour la première fois, je me demanderais sans doute pourquoi le programmeur s'est fait chier à écrire le read dans un block do-while aussi bizarre¹. Bref, il s'agit de connaître le langage qu'on utilise (pour lire ou écrire).

Donc, histoire d'enfoncer le clou sur cette histoire de décider que Perl est illisible/write-only/bla par définition, je maintiens que quelqu'un qui n'a (par exemple) jamais programmé en C ou en Perl, mais a de l'expérience en Common LISP par exemple, aura sans doute autant de mal à piger un programme que l'autre.

[1] Note que je ne dis pas que cette manière d'écrire soit top-moumoute. C'est juste un exemple à la con qu'on peut trouver (même si généralement des fonctions d'adaptations du genre xmalloc ou xread sont créées pour masquer ce genre de mécanique).

Question stupide : comment on s'en sort si EXIT_FAILURE est 0 et EXIT_SUCCESS 1?

Je cite le bloc de texte complet de la norme concernant exit et EXIT_FAILURE-EXIT_SUCCESS:

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS, an implementation-defined form of the status successful termination is returned. If the value of status is EXIT_FAILURE, an implementation-defined form of the status unsuccessful termination is returned. Otherwise the status returned is implementation-defined.

Donc la vraie valeur renvoyée au système par exit n'est pas nécessairement la valeur que tu lui fournis : un 0 peut être transformé en une valeur différente compréhensible par le système hôte.

Pour la question spécifique à EXIT_SUCCESS == 1; EXIT_FAILURE == 0, je n'ai rien vu dans la norme qui l'interdise, SAUF le fait qu'il est explicitement dit que EXIT_SUCCESS ou 0 en entrée signifie « succès », et que EXIT_FAILURE signifie « échec ». Donc si tu files 0 en entrée à exit, tu lui indiques « succès ». Bref, même si la norme n'indique pas explicitement que EXIT_FAILURE ne peut pas valoir 0, je pense que la formulation indique implicitement que ça entrerait en conflit avec la notion de valeur de succès. Une fois que exit a reçu sa valeur par contre, si en « interne » l'OS hôte a décidé que « succès » = 1, et « échec » = 0, c'est justement le boulot de exit de convertir les valeurs pour qu'elles soient correctement transmises au système (je ne sais pas si je suis clair).

D'après le standard de C99 (7.1.4.3—7.1.4.4) et le standard de C11 (7.22.4.5—7.22.4.6) :

Finally, control is returned to the host environment. If the value of status is zero or EXIT_SUCCESS , an implementation-defined form of the status successful termination is returned.

(l'emphase est de moi)

EXIT_FAILURE n'a pas de valeur attitrée, et donc il faut probablement toujours l'utiliser en cas d'erreur dont on n'a pas spécifié de codes spécifiques. Je citais un commentaire sur stackoverflow, mais principalement parce que j'étais d'accord avec le monsieur qui disait en substance « si tu n'utilises jamais EXIT_FAILURE, autant utiliser 0. Mais ne serait-ce que par symétrie, si tu utilises EXIT_FAILURE, autant utiliser EXIT_SUCCESS. »

Donc si, 0 est toujours une valeur correcte pour marquer une sortie sans erreur pour exit.

… Sauf que EXIT_SUCCESS est, aux dernières nouvelles, toujours égal à 0, et pas juste pour POSIX. Pour EXIT_FAILURE, je me range à l'avis de ce monsieur.

Il n'y a aucun argument technique qui pousse à utiliser la version octale, donc faire au plus lisible (quitte à se créer des constantes pour raccourcir)

C'est ce que j'essaie d'expliquer ici : en tant que développeur, je trouve que l'utilisation des valeurs octales est plus claire que l'utilisation des flags. Elle est plus concise, j'y suis habitué depuis avant d'avoir appris à programmer, et en un coup d'œil je peux lire et comprendre la valeur — 0644, 0744, 0700, etc., sont des valeurs que j'ai très vite appris à reconnaître. Pour moi, dans le contexte d'un soft qui ne vise que UNIX (et pire encore, Linux), l'utilisation de la notation octale est idiomatique.

C'est parce que ce sont des gens qui ne savent pas forcément très bien comment fonctionne un compilateur. Autant mon métier m'a appris que la phrase « le compilateur va optimiser pour nous » est relativement fausse dans pas mal de cas, autant j'ai aussi appris dans quels cas le compilo est bien plus intelligent que moi, et qu'il vaut mieux écrire du code « bête », mais qui sera correctement identifié par le compilateur, que faire des trucs bizarres qui vont rendre la lecture difficile à la longue.

Oui oui je sais, tout le monde m'est tombé dessus parce qu'ils n'ont pas compris ce que je voulais dire.

Mais non, on a bien compris que t'aimes pas les valeurs numériques juste parce qu'elles sont numé…

[…] on peut imaginer qu'un jour, on puisse vouloir changer les permissions attribuées au fichier, et ce jour là, il faudra que le patch modifie des trucs partout dans le programme, avec de grosses possibilités de bugs ou de modifs non nécessaires […]

Ah. Je euh. Oui. Effectivement, tu aurais dû commencer par là, parce que je fais partie de ceux qui n'avaient pas compris ton raisonnement. :-) Maintenant, je ne connais pas le code autour, mais je me dis que ce genre de trucs doit être sans doute « isolé » niveau fonctionnalité, et qu'il y a de fortes chances que ce soit le seul endroit où tu aies à changer les valeurs.

En même temps, que ce soit sous ViM ou Emacs, tu as les {c|e}tags. Sous ViM, un coup de C-] pour mater la définition, puis C-t pour revenir à ton bout de code, et c'est plié…

#define PI 3 // Ça va quoi, c'est bien suffisant pour 99% de nos problèmes ! 

[à propos des chemins en dur] Et le jour ou ca change, ils vont faire quoi? grepper sur /run/machin.

Franchement c'est très moyen. Surtout pour un soft dont le code évolue aussi vite, il serait clairement plus prudent d'avoir une constante au moins pour le préfixe. Et comme on parle de (as)printf, tu peux faire des trucs sioux du genre

printf(PATH_PREFIX "/le/reste/de/mon/chemin", ...);

… pour éviter des appels inutiles à str*cat/str*cpy pour des chaînes constantes.

Entre grepper surtout TOUS les fichiers (parce que tu ne sais pas forcément exactement quel fichier source utilise ce préfixe), ou aller changer le préfixe du chemin dans un seul fichier bien identifié (et sans doute documenté), tu penses vraiment que les méthodes sont équivalentes en termes de sûreté et d'efficacité ?

Bon, autant je suis d'accord pour dire qu'il y a plein de trucs qu'on pourrait arranger dans le bout de code cité, autant je fais partie de ceux à qui ont a appris en tant qu'utilisateurs de systèmes UNIX à utiliser chmod 644 monfichier avant de nous dire « ah oui y'a aussi des mnémoniques, comme chmod u+wr,go+r monfichier. D'ailleurs, autant j'utilise volontiers chmod +x toto ou chmod o+r titi, autant il a fallu que je cherche 2 minutes pour connaître la syntaxe de chmod pour attribuer des droits différents pour tous les utilisateurs en une seule fois.

L'utilisation de valeurs octales sous UNIX, dans le contexte de programmation système ne me choque vraiment pas. Dans le contexte d'une application de plus haut niveau, oui, j'utiliserais plutôt les flags qui vont bien.

Oui, tout objet est alloué sur le tas, mais ça ne veut pas dire que lors de l'instanciation d'un objet « pur données », le compilateur n'est pas capable d'en déterminer sa taille et d'allouer juste ce qu'il faut. En d'autres termes, si j'étais en C++, je pourrais faire un truc du genre (pas du tout efficace, mais pour montrer l'idée) :

// Allocation de tous les membres d'une structure sur le tas.
size_t   total_size = sizeof(int) + MAX*sizeof(wchar_t) + sizeof(Titi);
void*    memory     = operator new (total_size);
wchar_t* str        = new((char*)memory+sizeof(int)) wchar_t[MAX];
Titi*    t          = new((char*)memory+sizeof(int)+sizeof(wchar_t)*MAX) Titi;

// ...

*reinterpret_cast<int*>(memory) = 1;
*reinterpret_cast<wchar_t*>((char*)memory+sizeof(int))[0] = 'a';
*reinterpret_cast<Titi*>((char*)memory+sizeof(int)+MAX*sizeof(wchar_t)).someField = ...;

En Java je ne sais pas, mais au niveau système, Linux a tendance à recycler la mémoire allouée par brk (donc des données qui tiennent dans moins d'une page) plutôt que passer par l'allocation depuis une nouvelle page (pour des raisons de perfs évidentes). En fait, tout un tas « d'allocateurs de petits objets » ont été proposés par le passé pour plusieurs plates-formes, comme par exemple dans Modern C++ Design, où Alexandrescu décrit un allocateur de ce genre qui exploite les capacité du « placement new ».