zul a écrit 443 commentaires

Le troll n'était pas sur la beauté intrinsèque de la page man, mais qu'il bashait OpenBSD, en citant une page de man de MacOSX, système qu'il défend régulièrement par ailleurs. Bref, ça m'a fait bien fait rire, mais il m'en faut peu.

Le shell, ça permet de faire un peu plus de chose que systemd, genre c'est un outil de base pour administrer / jouer avec un unix, pas juste l'init. Enfin, je suis sûr qu'on finira par avoir un lennartsh avec sa syntaxe propre, plus "moderne".

Cool, 5 entreprises PRISM compliant pour auditer une bibliothéque critique. Ayez confiance, ayez confiance, braves petits :)

Le standard support par la lib. "std" c'est la lib standard, rien à voir avec Posix, pour la version le bohneur est que c'est très très compatible entre les versions.

Arrête de t'énerver, ton orthographe s'en ressent fortement. Et je suis encore très déçu de te dire que stdio.h et la libc contiennent des fonctions standardisées POSIX et pas juste C, par exemple fdopen (elle est même présente chez Microsoft). Ça peut te choquer mais c'est comme ça.

En l’occurrence, et pour être très précis, tu dis

Il auraient voul aider la portabilité qu'ils auraient largement éviter de polluer les includes de la lib standard, ils auraient pris un autre nom pour leur include, en respectant le côté standard des includes standards.

Je note juste que c'est une pratique commune, qu'on peut dénoncer si ça te fait plaisir, mais ce n'est justement pas mieux / pire que chez les autres. Je n'ai pas parlé de pourris, je n'ai pas dit de mal de Microsoft, j'ai donné un exemple dans chaque système majeur, je peux pas être plus "égalitaire".

Bon, de toutes façons le but n'est pas d'être cohérent, mais de dire que du bien d'un truc qu'on a déjà choisi que ça serait bien. J'arriverai à jour à comprendre qu'on ne peut pas montrer des petits problèmes à des gens qui veulent ne pas voir de problèmes.

C'est une excellente remarque, surtout appliquée de manière réflective. Et va voir un psy pour ton délire de persécution … (c'est gratuit, en avance pour demain).

#if not defined(__OpenBSD__)
#include "compat.h"
#endif

Pas besoin de modifier stdio.h. Ensuite, pas la peine d'accuser OpenBSD, comme indiqué très clairement dans la man page, c'est très largement du prior art, i.e 4.4 BSD. Et sinon, magnifique la page de man de MacOSX … :D

Je sais pas pour vous, mais moi quand je lis "include "stdio.h"", je m'attend à ce que seulles des fonction standardisées soient utilisées.

Sérieusement? Tu vis dans un monde de bisounours ou tu es mauvais en C au choix :). Déjà quel standard ? C89, C99, Posix (quelle version ?) Quelques exemples pour ta culture:

• sous Windows, stdio.h définit _snprintf, fonction bien connu des standards.
• Sous GNU/Linux, tu peux trouver fcloseall. Y'en a évidemment d'autres.
• Sous Android, tu retrouve funopen (les salauds ils ont piqué une libc BSD :)).

Pour le reste, je te laisse troller dans ton coin :)

Captain Obvious à la rescousse! Tu espérais quoi, un truc qui prouvait la correction par l'opération d'un esprit supérieur ?

C'est sûr qu'on peut faire la même confiance dans un code C spaghetti de 100K lignes et dans 500 lignes de spécifications dans un langage formel quelconque (chiffres complétement au pifomètre).

Une exagération très légère… Si le langage choisi (F7 pour le travail de Prosecco) est bien fait, toutes les failles d'implémentation devraient être décelées.

Non, c'est clairement exagéré. Toutes celles pour lesquelles on a écrit des "preuves". Une approche formelle ne garantie rien "magiquement". Par exemple, dans mitls, il n'y a pas de modélisation explicite du temps, donc on ne peut rien prouver sur les "timings attacks" (ce qui ne veut pas dire pour autant que leur implémentation est incorrecte de ce point de vue là).

L'autre question évidemment est la possibilité d'embedder ça dans les différents logiciels, je ne suis pas trop sûr de l'interoparibilité de F7

Un peu comme Coverity (ça pue c'est pas libre mais ça trouve quelques bugs). En l'occurence, il n'avait pas detecté le bug dans OpenSSL.

Ils ont même fait une page wiki pour répondre à ta questions

http://www.haskell.org/haskellwiki/Haskell_in_industry

Si le mail commence à avoir des images, un CR de réunion, des fichiers attachés qui sont transférés… on peut arriver à plusieurs centaines de Ko et au final une discussion de plusieurs Mo alors que quelques centaines suffisent.

Un client mail digne de ce nom ne renvoie pas les pièces jointes quand on répond. Reste le texte qui est de taille anecdotique, et [snip] pour supprimer l'information sans contexte pour la réponse. En entreprise, c'est très mal utilisé certes, mais est ce vraiment un problème de protocole ?

Quel problème de volumétrie surtout ? Un mail correct, ça fait dans le(s) Ko.

Pourquoi tu dis que c'est proprio ? C'est spécifié dans la RFC 2822.

Les fichiers de déclarations ne sont pas un problème en soit je pense. Le problème c'est qu'en C, C++, #include, c'est vraiment juste une inclusion textuelle, et donc que le compilateur doit reparser tous les fichiers tout le temps, ce qui rend les temps de compilation assez horrible. Un simple Hello world après subsitution de #include fait, chez moi, 18K lignes.

En quoi est il dépassé ?

l'anti-spam ultra-efficace

Franchement, la politique anti-spam de google, je ne la trouve pas super efficace. Déjà, il a réussi à classer des mails venant de leur propres prestataires en spam, c'est vachement impressionant. Couplée à la stratégie qui fout les spams dans un folder spécial, qui est automatiquement vidé tous les 30 jours, ça te laisse bonne latitude pour perdre des mails utiles.

Thunderbird fait ce qu'il faut, ie. indiquer ce qu'il pense être un spam, et laisser l'utilisateur décider en dernier recours. C'est chiant dans 99% des cas, mais il est complétement intolérable de perdre seulement 1 mail important.

Oh, et c'est partenariat de MS Research et l'INRIA

C'est bien de mettre en exergue la qualité des labos français pour une fois :D

. 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é.

Pour la spec C89, c'est indéfini. Pour C99 et C++, ça doit retourner 0. Le comportement de gcc est consistent avec le comportement défini par la norme (clang a l'air de toujours retourner 0, même en C89, ce qui est une implémentation valable en soit :)).

Ça n'a évidemment aucun interêt en soit, à part d'être passer à une autre fonction, genre qsort (ce qui répond à la question du prototype).

Historiquement, c'est plutôt le contraire mais c'est ça l'idée. Portage, c'est une réécriture de ports / pkgsrc en utilisant des outils "modernes" (en l'occurence Python).

C'est utilisé par défault par NetBSD. Il y'a d'autres utilisateurs (genre SmartOS). Je l'ai longtemps utilisé sur mes slackware. Jusqu'à peu, c'était aussi le système par défault de DragonFly. Et j'en oublie très certainement.

4 return, alors qu'il y a un free(p) qui traine

Ça a l'air correct.

D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof

C'est du C. On a l'habitude d'abuser la sémantique. Si c'est "proprement" documenté :). Pas choqué

Des magic values 0700, 0600.

Ça pinaille là. Ce sont des droits Unix. On peut utiliser les constantes symboliques, mais ça n'apporte pas grand chose, voir c'est contre-productif.

Des chemins codés en dur

C'est un peu moche, mais c'est de la tambouille interne. Comme de toute façon, ils ont décidé que /run devait existé, et qu'ils utilisent un "namespace" propre, ça ne risque pas grand chose.

Bref, ce bout de code m'a l'air correct. L'autre asprintf par contre est clairement incorrect.

Mon dieu, surtout pas! La rencontre des deux systèmes d'exploitation systemd et emacs pourraient provoquer une catastrophe sans précédent, peut être la création d'un super trou noir ou je ne que sais quoi de pire :)

On peut trouver plein de choses à dire je suis sûr :).

Concernant la spéculation, certains te diront qu'elle est un cancer pour l'économie. Point à la ligne. Elle a certes joué un rôle économique, mais elle est aujourd'hui complétement flouée. Bref, que ce soit sur fond propre ou dans un cadre contractuel (même si j'avoue ne pas comprendre ce que tu sous-entend), on peut le placer dans richesse illégitime.

Même l'héritage peut être considéré comme une richesse illégitime (dans le sens où tu ne l'a pas gagné). L'héritage, c'est le mécanisme qui permet aux riches de s'enrichir de plus en plus à chaque génération, et de creuser in fine les inégalités. C'est "la raison" pour laquelle l'Etat prélève un pourcentage sur l'héritage pour "lisser l'inégalité" (même si ça reste assez peu efficace au final).

Ma question était plutôt de savoir ce qui leur faisait penser que la terminaison d'une fonction récursive est plus difficile à analyser que du code impératif sphagetti avec des boucles à gogo :)

Le problème de la récursivité, c'est que, basiquement, à chaque sous-appel d'une fonction récursive, tu empile un nouveau contexte de fonction, ce qui augmente donc la pression sur la pile qui est de taille limitée. Si tu fais trop souvent, paf, tu peux exploser ta pile, faire un "stack overflow" avec possiblement plein de conséquence pas drôle. C'est ce qu'ils expliquent un peu slide 26 (même si certains arguments me paraissent fallacieux, entre autre sur la terminaison).

Tu peux faire de l'analyse de l'espace mémoire nécessaire en connaissant ton facteur max de récursion, et combien te coûte exactement chaque appel sur la pile mais c'est évidemment plus compliqué que d'analyser une bête boucle.

Ce problème peut être mitigé si tu fais de la récursion terminale, et si le compilateur implémente le tail-call optimization. Dans ces cas là, tu n'empile pas de contexte de fonction, et tu as le même coût en mémoire qu'une simple boucle. OCaml et d'autres implémentent cette optimisation, mais ce n'est pas le cas de la majorité (voir tous) compilateurs C.

C'est vrai que la "communauté Windows", pour autant que cette chose existe (autant que LA "communauté Linux") est ouverte d'esprit et propose toujours des outils interopérables, respectant les standards et toujours poli et agréable avec les gens n'utilisant pas leur sacro-saint système. Ne parlons même pas de la "communauté MacOSX" …