lasher a écrit 2753 commentaires

Bah, il suffit de lancer Visual SysAdmin++. Qu'il est bête lui alors.

Tu veux dire comme Lenovo qui m'installe Office 2010 par défaut mais sans clef d'activation ?

Ils ont violé la GPL ? Gné ? Quand ça ?

[Google] est un préjudice commercial considérable. Google n'a pas a s'en servir pour s'autoriser des trucs, illegaux ou non.

Pourtant, y'a des fois je les comprends un peu: quand cnet a lancé une histoire où ils cherchaient à avoir des infos sur Google et ses patrons, ces derniers n'ont pas apprécié. Et quelque part, je les comprends. L'information est facile à trouver sur le net certes, mais le travail d'agrégation de cnet n'était pas génial.

Bon maintenant, les chefs de Google ont bon dos d'expliquer que la notion de vie privée, c'est du passé.

Mince, dans y'a 2-7 ans, faudra que j'arrête. :-(

Mais bon, c'est normal, il est temps que je passe au hip-hop, au R'n'B, à la techno…

Toi tu connais pas ma maman.

C'est d'ailleurs pour ça qu'entre la page de manuel de (disons) scanf, et ce qu'on peut trouver sur le net pour expliquer son fonctionnement, ça peut donner ça : http://xrenault.developpez.com/tutoriels/c/scanf/

Par là je veux dire: certaines fonctions de la bibliothèque standard sont juste mal foutues, point. À l'époque elles avaient peut-être du sens, mais le langage C est loin d'être simple (enfin, sa syntaxe et sa grammaire le sont, mais pas son utilisation).

Ensuite, concernant strncpy/strncat: « il suffit de lire la doc » ? Vraiment ? C'est pour ça que, malgré la ressemblance entre les deux noms, chaque fonction a une page de manuel super étendue je suppose, avec des comportements différents pour que ce soit encore plus rigolo (et encore, elles étaient bien plus succintes il y a dix ans) ?

Ça donne de joyeux bouts de code du genre :

char *src;
char dst[size+1];
char buf[K*size];
size_t len = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

/* strncpy() copie au maximum "size" caractères de la chaîne src vers la chaîne dst. 
 * Mais attention ! Si la longueur de src dépasse "size", alors il n'y aura pas de '2878b2550166f39398d09567f242898acfb5ed97' 
 * final ! Il faudra le rajouter à la main du coup.
 */
len = strlen(src); /* il faut espérer que src est bien terminé par '\0'... */
strncpy(dst,src,size); 
if (size <= len) 
    dst[size] = '\0';

/* ... */

process(buf,...); /* traitement de buf, qui contient une certaine chaîne de caractères au retour de l'appel */
len = strlen(buf); /* il faut espérer que buf est bien terminé par '\0'... */
/* Rigolons un bon coup. strncat() prend un taille en troisième paramètre. 
 * Si celle-ci est plus grande que la taille de ce qu'il faut concaténer, 
 * "tout va bien" : strncat rajoute un '\0' juste après le dernier caractère copié. 
 * Bon bien sûr, maintenant, j'ai beau avoir demandé N caractères max à concaténer,  
 * si ma chaîne source contient plus que n caractères, alors strncat va écrire n+1 
 * caractères.
 */
strncat(buf,dst,K*size-len-1); /* Comme quoi, c'était pas si compliqué ! */

et faire un truc du genre

char *src;
char dst[size+1];
char buf[K*size];
size_t len1 = 0, len2 = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

len1 = strlen(src);
memcpy(dst,src,size);
dst[size] = '\0';

/* ... */

process(buf,...); 
len2 = strlen(buf); 
size_t tmp = len1+len2+1 <= K*size ? len1+len2 : K*size-1;
memcpy(buf,dst,tmp);
buf[tmp] = '\0';

Ou encore :

char *src;
char dst[size+1];
char buf[K*size];
size_t len1 = 0, len2 = 0;

/* ... src est alloué, initialisé, etc. quelque part ici ... */

len1 = strlen(src);
memcpy(dst,src,size);
dst[size] = '\0';

/* ... */

process(buf,...); 
len2 = strlen(buf); 
if (len2+len1 < K*size)
    strcat(buf,dst); /* La concaténation est sûre */
else /* K*size < len1+len2 */
{
    memcpy(buf+len2,dst,K*size-len2-1);
    buf[K*size-1] = '\0';
}

Ah si: au moins, dans le deuxième cas, tu ne te poses pas la question de « est-ce que c'est strncat ou strncpy qui rajoute un \0 additionnel ? »: dans tous les cas tu as un comportement éprouvé (i.e. tu ne manipules que des bytes). Bon bien entendu, t'es niqué quand le byte fait 1 octet, mais que le char en fait 2 (comme ça peut arriver sur certains DSP).

Ce n'est pas pour rien que les dévs OpenBSD on rajouté strlcat/strlcpy: non seulement le comportement des fonctions est homogène, mais en plus elles renvoient une vraie information utile : le nombre de caractères copiés (au lieu du pointeur destination que tu as toi-même passé en paramètre au moment de l'appel…).

char *src;
char dst[size+1];
char buf[K*size];

/* ... src est alloué, initialisé, etc. quelque part ici ... */

size_t src_len = strlen(src);
size_t cpy_res = strlcpy(dst,src,size); /* J'ai la garantie que dst est a un '\0' */
if (cpy_res < src_len) {
    /* Gestion de la troncature */
}

/* ... */

process(buf,...);
size_t buf_len = strlen(buf); 
size_t cat_res = strlcat(buf, dst, K*size);
if (cat_res >= buf_len) {
    /* Gestion de la troncature */
}

(Il est tard au moment où j'écris ces lignes, et il y a de fortes chances que j'aie fait une erreur : je n'ai pas compilé pour vérifier)

Donc voilà. Je suis surpris que tu te permettes de dire que « y'à qu'à bien savoir compter », alors que même les développeurs d'environnements qui se veulent sécurisés disent que strcpy/strcat Vs strncpy/strncat est une fausse « sécurité ». Je me souviens avoir entendu et lu Marc Espie à plusieurs reprises concernant le fait que, même plein de bonne volonté, le dév qui cherche à remplacer ses strcpy/strcat par strncpy/strncat va souvent se planter à cause de la différence de sémantique dans les deux fonctions. Alors qu'au moins avec strcpy/strcat, la règle est simple : tu vérifies la taille de tes buffers avant de faire quoi que ce soit (et bien entendu, avec strlcat/strlcpy, c'est ENCORE plus simple).

Surtout, la loi est la mise en œuvre d'une certaine vision morale de la société, dans la durée. Contrairement à l'éthique qui peut varier très vite d'une personne à une autre, sur de courtes périodes, etc., la morale « ambitionne »¹ de fixer des limites absolues (jusqu'à ce que la société change sur ses codes communs).

[1] Je mets entre guillemets parce que bon, personnifier un concept, c'est pas très joli...

Il a le droit d'exiger un prix pour ce qu'il réalise. Tu as le droit de ne pas acheter. Et je parle d'un auteur dans le sens « personne dont la profession est d'écrire » bien entendu. Il produit un travail d'écriture, et il peut demander une rétribution d'ordre pécuniaire en échange. Je ne vois pas ce qui te fait tiquer ici.

OCaml, LISP ou F# sont de bons exemples, oui.

Je n'accepte pas non plus le terme « privateur » pour le logiciel. Sinon la GPL me prive du droit de rendre le logiciel fermé. Alors que la BSD non.

Bref.

J'estime que tout auteur a le droit de vivre d'œuvres de l'esprit (c'est la moindre des choses). Les deux choses que je remets en question sont :
1. Quel est le prix le plus juste pour le public ?
1. Combien de temps doit-on attendre avant de rendre l'œuvre « publique » ?

Pour le 1., je trouve que les éditeurs musicaux n'ont que ce qu'ils méritent : ils avaient promis que, le coût de production des CD aidant, le prix des CD serait bien moindre que celui des vinyles. Il a fallu attendre Napster et les maychants pirates pour que le prix des CD descende enfin significativement, après des années d'abus.

Tiens au fait, mon père attend toujours la réédition promise de tous les vinyles de musique classique qui n'étaient plus dispo « parce qu'on va les remplacer par des CD monsieur ».

Non, ce n'est pas un pouvoir du tout. C'est accepter de se priver. Mon discours ne s'effondre pas plus qu'avant : on cherche à me vendre des DVD et des CD, bien plus que de la bouffe (j'exagère, je sais :)). Ben voilà, la réponse est « j'achète ce que je peux, je télécharge le reste ». Et quand t'es ado, j'insiste, mais justement tu es la cible principale. Et un ado c'est à la fois une super cible (influençable et tout) et la pire (la moins autonome, avec le moins de fric). Je ne vois pas où est le mal à ce que quelqu'un qui n'a de toute manière pas les moyens de payer ce avec quoi on le nargue à tout bout de pub (radio, télé, internet), et qui en plus n'enlève rien au « propriétaire » du contenu.

J'ai recommencé à télécharger justement quand les lois liberticides sont arrivées. Je veux qu'on m'explique pourquoi je paie des taxes sur mes supports de stockage au nom de l'exception sur la copie privée, mais qu'en plus on veut fliquer ce que je veux faire. En attendant, mon instinct de contradicteur rentre en action.

Je refuse cet amalgame entre « privateur » et les autres. Aucune œuvre artistique n'est privatrice. Une œuvre ne me prive de rien en elle-même.

Stwa privateur !

Chacun est responsable de ses actes.

C'est vrai, mais quand une organisation (disons par exemple la FNAC, Virgin, ou Universal…) a des amis bien placés au gouvernement et qu'elle peut par cette entremise sensibiliser les patrons des élus (et les élus eux-mêmes) à la dure vie des disquaires multi-spécialistes, de la création de « produits musicaux », et qu'au final lesdits patrons reconnaissent que décidément, 50 ans après la mort de l'auteur, ce n'est pas assez, et que 70 ans c'est bien mieux, je me pose des questions sur les armes qui restent au simple citoyen (qui peut, soit dit en passant, être lui aussi un artiste) pour lutter.

Ah ben y'a un truc simple: quand les puissants proposent des choses (bouffe, toit, ou tout bêtement chanson pourrie de Britney Spears ou enregistrement HD d'un concerto de Bach pour violon) à des prix ou conditions déraisonnables, la seule arme du peuple c'est la révolte ou la désobéissance civile.

Individuellement, les gens du peuple ont moins de pouvoir que les gens du gouvernement. Collectivement, ils peuvent faire bouger les choses, tout simplement en refusant d'appliquer des lois injustes. La différence, c'est que pour le moment, il n'est pas nécessaire de se regrouper sous un nom commun pour faire front, car tout un chacun peut télécharger depuis chez lui.

Enfin, je sais, c'est un argument éculé, mais j'aime bien le ressortir de temps à autres : quand j'ai découvert Napster il y a plus de 10 ans, j'étais un ado sans sous, mais avec une connexion internet illimitée via le câble. J'ai du coup téléchargé des dizaines d'heures de chanson de groupes que je connaissais déjà ou dont j'avais entendu parler par des amis. Et je maintiens que lesdits artistes n'ont jamais perdu un centime avec moi, car je n'avais pas les moyens de leur payer quoi que ce soit. Mieux, cet accès « gratuit » m'a permis de connaître tout un tas de morceaux (ainsi que leurs auteurs) qui sans cela n'auraient pas fini dans ma discothèque¹ (parce que oui, je paye la majorité de ma musique, désormais, quand elle n'est pas libre — et elle l'est peu souvent — parce que maintenant j'ai les sous pour le faire).

Donc voilà, j'assume. Il m'arrive de copier de la musique (bouuuuuh), des films (bouuuuuh), des BD (BOUUUUUUH), tout ça. Et à côté de ça, je manque de place pour caser toutes les BD, tous les bouquins, les CD, DVD, etc., que j'ai payés en 10-15 ans. Bref: j'attends ENCORE qu'on me démontre que le « piratage » est nuisible aux artistes en général. Ah oui, et parfois, avant même Internet, je copiais depuis une cassette ou un CD ! Mais quelle graine de délinquant je fais ! Ah pardon, on me fait signe dans l'oreillette que ça c'est autorisé, parce que ... parce que quoi au fait ?

[1] Par exemple : sans les mp3, je n'aurais jamais entendu parler des VRP, des Nonnes Tropos, de Tori Amos, de Nine Inch Nails, Grip inc, et beaucoup, BEAUCOUP d'autres.

Certes, mais dans un cas tu dois te soucier de l'impact de ton code sur la machine (genre le C range les données par ligne pour les tableaux 2D, alors que le Fortran le fait par colonne), dans l'autre (Java, C#, etc.), tu devras sans doute t'y intéresser à terme si tu veux de vraies perfs, mais sans doute pas aussi vite.

De plus, C et Fortran peuvent compiler sans pour autant être toujours capables de t'avertir de tous les problèmes potentiels que des langages tels que Java ou C# ou autres détectent. Et dans un cas (C/Fortran) je peux avoir une exécution erronée alors que dans l'autre le compilateur n'aurait simplement pas accepté de compiler.

Beurk. Et si j'ai un tableau à 5 dimensions? Dans un cas j'ai tab(i,j,k,l,m), qui fait correctement ce qu'il faut, dans l'autre, j'ai tab[i][j][k][l][m] qui fabrique tout plein de proxys juste pour pouvoir émuler la notation des tableaux classiques en C...

Je suis bien d'accord. :) Cela étant dit, je parlais de langages de plus haut niveau en général, pas uniquement de Java (Perl, Ruby, Python, etc. sont pour moi de bons candidats).

Je crois que tu as tort. :)

Les noyaux de calcul (par exemple une tuile pour faire une multiplication de matrice) ont généralement des bornes fixées à la compilation (en fonction de la taille des différents niveaux et tailles de cache, etc.). Cependant, on se retrouve avec des algorithmes généraux pour gérer des tailles arbitraires. Dans les codes de HPC que j'ai croisés jusqu'ici, les bibliothèques pour le calcul intensif sont bien entendu optimisées et spécialisées, mais les programmes traitent des entrées de taille arbitraire.

Non mais attends, c'est même pire que ça, en plus, si tu veux faire dans le multidimensionnel, C++ c'est nul, il faut passer par () et pas par [], parce que sinon ça passe pas. Quel fourbe ce Bjarne !

Concernant le modèle mémoire de C, il ne faut pas s'attendre à des miracles. Quand on voit le modèle suivi par C++...

Eeeeuh, tu es sûr de ton coup là ? Parce que tout ce que je vois, c'est une lvalue et une rvalue qui utilisent le même objet. Du coup, c'est un comportement indéfini, si je ne m'abuse (et le compilo peut faire ce qu'il veut, même décider d'aller commander un sandwich sur le net s'il veut).

Je suis plutôt d'accord (même si toutes tes réponses dans les commentaires de cette dépêche ont tendance à être un chouïa trop agressifs à mon gout...). Hors domaines extrêmement spécifiques comme l’embarqué [1], le calcul haute performance [2], et dans une certaine mesure les jeux vidéo [3], le reste du temps, je préfère des langages qui me garantissent plus de choses que ce que C et C++ offrent. J'adore le C, j'aime bien le C++, mais c'est parce que j'ai un coté bidouilleur (et que je bosse dans le HPC, donc C+assembleur c'est assez fréquent). Par contre bizarrement, quand j'ai du traitement de chaines a faire de façon un peu intelligente, ou bien d'autres petits traitements (sur potentiellement de gros volumes de données), je ne sais pas vous, mais je préfère quand même bien plus des langages de plus haut niveau ou en tout cas qui vont me permettre de réduire mon temps de développement (grâce a une bonne analyse statique, parce que le langage lui-même propose des constructions de haut-niveau tels que des tables de hachage, des tableaux dynamiques, etc.).

Le C et le C++ ne devraient être utilises selon moi que si la performance est un enjeu critique pour la majorité de l'application. Dans l’idéal bien sûr, on voudrait de la performance partout. En pratique, optimiser un bout de code pour une architecture particulière peut prendre des semaines, voire des mois. Et à, c'est en supposant qu'on est certain que l'algo utilise est le meilleur pour la tache donnée (et dans un contexte donnée).

[1] Je parle vraiment de matériel avec juste "une" tache bien spécifique a réaliser (avec des contraintes de puissance de calcul et d'espace mémoire drastiques), pas un machin qui peut se permettre d'avoir une JVM embarquée...
[2] Par calcul haute performance, je pense au traitement vidéo, a diverses simulations en physique et chimie, a l'utilisation de gros calculs mathématiques (par exemple de l’algèbre linéaire creuse ou dense), mais aussi au parcours de graphes en parallèles.
[3] Dans une certaine mesure parce qu'une bonne partie est réalisée a l'aide de langages de scripts customisés pour un moteur donné.

Cf. la réponse de brendel pour les problèmes de bornes.

Fortran ET C sont de relativement bas niveau. Les deux forcent le programmeur à faire attention à ce qu'ils font pour (presque) chaque ligne de code. Cependant, Fortran propose EN PLUS des construction spécifiques pour le calcul (addition de vecteurs, etc). J'aurais pu être plus explicite, il est vrai.

Si le compilo peut le faire de toute manière, bien sûr que ce serait cool. Cependant, ça va juste retarder le moment où tu vas devoir repenser ton algo pour gérer des entrées au problème 100 fois plus grandes...

En haute performance, on utilise pas la vérification automatique de dépassement de taille de tableau, car le seul moyen de le faire correctement, c'est de vérifier les bornes pour chaque accès (et ça coûte énormément en temps CPU). C'est un des cas où l'utilisation de Fortran, C ou C++ a plus d'intérêt que Java par exemple:

• C te force à tout penser, et puisque de toute manière on parle de calcul haute-perf, ça « va de soi » (et c'est bibi qui doit optimiser le tout ensuite...)
• Fortran propose tout un tas de constructions de relativement haut niveau concernant le calcul scientifique. Par exemple, si A et B sont des tableaux de même taille, je peux faire A=A+B et le compilateur va automatiquement générer le bon type de code: SSE pour x86/x86_64, Altivec pour PowerPC, etc.
• C++ n'est pas qu'un langage orienté objet. Comme le dirait S.Meyers (Efficient C++), il s'agit de plusieurs « langages » (ou dialectes) en un: C, C-avec-classes, templates, et STL. En HPC, on a tendance à utiliser C++ en tant que C + templates + surcharge des opérateurs (pour pouvoir reproduire ce que Fortran permet de faire nativement, et étendre le tout à de nouvelles structures données).