David Marec a écrit 472 commentaires

Ok, merci. J'ignorais que le monde du cloud proposait ce genre de choses.

Je comprend que c'est limité à un usage particulier, orienté pour digérer les informations/traces/données négligemment laissées par les utilisateurs du service
et qu'il n'est pas possible de programmer le FPGA librement.

Tristan Nitot affirme que cette nomination n'a pas de lien avec les récents problèmes (et l'avalanche d'articles qui s'en est suivi) de Qwant.

Je ne sait pas trop de quoi il s'agit en fait, j'ai du passer à coté de l'« avalanche ».

Du coup, en fouillant un peu, je suis tombé sur :

• tristant Nitot justifie le choix de migrer sur les serveurs microsoft

En particulier:

mais Microsoft, avec son Cloud Azure, nous permet de faire des calculs de type FPGA

J'ai du mal à croire que le moteur de recherche ait du code dans des FPGA, qui seraient de plus fournis par Azure.

De quoi s'agit-il ? Que signifie vraiment ce « calculs de type FPGA » ?

Les dernières versions du compilateur XLC d'IBM sont basées sur LLVM

Ah bon. J'ai toujours cru qu'il n'utilisait que CLang, c'est à dire uniquement le language front-end.

Et tu pourras toujours te brosser pour avoir les modifications apportées Martine

S'il ne s'agit bien que du front-end, l’intérêt d'avoir les modification est réduit.

Son témoignage accuse Epstein, pas Minsky

Pas exactement, elle accuse d'abord sa collaboratrice (dont j'ai oublié le nom).
Ensuite, elle indique qu'elle a eu des relations sexuelle avec Minsky, ce qui est nié dans le fil sur reddit.

---

de mémoire, je n'ai plus les sources sous la main.

Suivant les derniers développements, il semble que Minsky n'ait finalement eu aucune relation avec cette adolescente

Quels derniers développements ? le même lien qui tourne vers les commentaires sur reddit ?

La victime a été entendue en 2016 et c'est de son témoignage dont il est question, je suppose dans « reference report» .

Ce qui n'empêche pas les commentateurs sur reddit de balayer tout cela d'un revers de main sur la
base d'un témoignage d'un type qui n'était pas là, mais à qui on aurait dit que…

---

Lien que nombre de gens ici n'hésitent pas à faire tourner.

Et puis à chaque fois qu'on lynche quelqu'un, on est du côté opposé à celui qu'on lynche, donc du bon côté

Ben, c'est pour ça qu'on lit « Le Monde » , d'habitude.

Quelle enquête ?

Celle de 2016.

Une femme accuse un mort (Jeffrey Epstein) de l'avoir proposée comme objet sexuel
à un autre mort (Marvin Minsky).

Epstein était vivant, lors de la déposition de la victime.

Tu as oublié la désallocation :'(

Ou pas …

Sur les systèmes les plus utilisés, dont Linux, la libération sera effectuée de toute façon en sortie de programme.

Tant que l'allocation est contrôlée, la libération est inutile.

De mon temps, c'était plus facile de lire l'assembleur produit par gcc, (c'était du 32 bits) !

Précisez -fverbose-asm à GCC.

Pour être plus précis, il ne s'agit pas d'un programme, mais d'une option de GCC : Wvla.
- qui existe aussi pour CLang.-

j'ai même pas compilé ce code, j'espère ne pas dire de grosses connerie

Ça devrait fonctionner comme ça.
J'aurais casé un calloc pour que ça fasse encore plus tableau, par contre.

Il ne s'agit pas seulement du compilateur, mais de tout l'environnement, la toolchain.

On ne peut pas compiler le noyau linux ou un module en C11 par exemple, même avec GCC8.

---

Et n'essayez pas d'introduire une déclaration de variables dans vos boucles, vous allez vous faire engueuler par Linus.

La règle que j'applique aujourd'hui est que je place la dernière version EOL du noyau qui précède la stable actuelle. Cela m'évite de compiler plusieurs versions mineures.

Euh, pourquoi ?
Il pourrait y avoir des apports intéressants dans une version mineure, voire des corrections de failles.

La vrai difficulté est de suivre ces modifications et de savoir lesquelles pourraient vous être utiles (selon les architectures, vo applications, les drivers …).

Et c'est valable pour d'autre OS.

Par exemple, j'ai des machines sous FreeBSD.12-Stable et je dois suivre les commits sur cette branche pour savoir si oui ou non, ça vaut le peine de prendre le risque de rebooter sur une nouvelle révision.

---

En fait, je prend souvent ce risque. parce que même pas peur.
( et que zfs send/zfs recv incrémental tous les jours vers une autre machine, aussi.)

Sinon, je (re)compile du FreeBSD dans les trois à quatre fois par semaine.

De fait, je, c'est beaucoup dire: je confie cette tâche à des scripts Makefile qui, in fine, demandent à clang d'effectuer le gros du boulot.

c'était rock and roll…

Bof,le vrai rock'n'roll, c'était Téléchat.

La seule émission pour enfants qui faisait peur aux mômes.

---

Ailleurs aussi, Topor a fait du vrai rock'n'roll.

Si size vaut 0 alors result est égal à null

Peut-être, mais c'est la valeur de result qui est importante, c'est lui la clef - et le résulat- des allocations. Dîtes vous que c'est (ou ça devrait être ) l'inverse:

• Si result est NULL alors size vaut 0.

et le calloc reste essentiel !

Et non !

si result est NULL:

• calloc(len+1,1) == malloc(len+1)== realloc(*result,len+1)

Et, je le répète:

• sizeof(char) vaut 1, quoiqu'il arrive. C'est le même la seule taille de type qui soit garantie.
• N'utilisez donc pas calloc mais malloc.
• ptr=realloc(NULL,size) est équivalent à ptr=malloc(size)

Man realloc:

If ptr is NULL, the realloc function behaves
identically to malloc for the specified size

Le code rectifié est le suivant:

qui doit être équivalent à ces seules lignes:

if(*size < len){
    *result = realloc(*result, len + 1 );
    *size=len;
}

avec size affecté en dernier.

Ce qui change tout. Ceci dit, je reste persuadé qu'il vaut mieux encadrer result plutôt que size pour déterminer qui est déjà alloué et qui ne l'est pas encore.

---

moins il a de branches, mieux se porte le code.

Il suffit de pointer sur un membre du tableau:

#include <stdio.h>
#include <string.h>

#define MAX_RESERVE_NOM 21
#define MAX_NOM (MAX_RESERVE_NOM - 1)
#define FAMILLE_SIZE 10
struct famille
{ 
    int age;
    char surnom[MAX_RESERVE_NOM];
    char nom[MAX_RESERVE_NOM];
};

/* pour le confort */
typedef struct famille* familleptr;

/*-----------------------*/
void changement(familleptr m)
{ 
    m->age=18;
    /* strncpy: pour ne pas deborder */
    strncpy(m->surnom,"plouf6789ABCDEFGHIJKZZZZ",MAX_NOM);
    strncpy(m->nom,"plaf",MAX_NOM);
}
/*-----------------------*/

int main(void)
{
    struct famille membre[FAMILLE_SIZE]={ 
        {10,"pif","paf"},
        {11,"dede","lulu"},
        {12,"",""},
        {13,"",""},
        {14,"",""},
        {15,"",""},
        {16,"",""},
        {17,"",""},
        {18,"",""},
        {19,"",""}
    };

    strncpy(membre[2].surnom,"pof",MAX_NOM);
    changement(&membre[3]);

    for(size_t i=0;i<FAMILLE_SIZE;++i){
        printf("Le surnom de %s, agé de %d années, est %s\n",membre[i].nom,membre[i].age,membre[i].surnom);
    }
    return 0;
}

---

«membre», avec un «m» avant le «b»

je vais tenter d'expliquer cette partie du code:

Faites mieux: vérifiez vous même, à l'aide d' assertion.

Par exemple, avant d'allouer:

assert(result!=NULL);

ou avant d'affirmer:

ne peut pas être égal à 0

if(!*size){
assert(len!=0);
/* … */
}

Si vous souhaitez collaborer à la conception de ce module destiné à la création de nouveaux modules

Dans un premier temps, mettez vos sources à disposition en téléchargement, de préférence avec un système de gestion de version au dessus.

je vais tenter d'expliquer cette partie du code:

Clairement: tout ce que je vous indique est valide, quoi que vous fassiez en amont.

[SNIP] Il est censé être ré-allouer

Ré-allouer, c'est appeler realloc, pas calloc. Je le répète: vos appels à calloc n'ont pas de sens:

1. la taille demandée est toujours 1 ( sizeof (char) ): utilisez malloc.
2. Vous ne vérifiez jamais que result n'est pas null donc que result se doit d'être libéré avant d'appeler calloc.
3. Petite astuce realloc fonctionne comme un malloc si le pointeur n'avait pas été alloué en premier lieu. Vous pouvez l'utiliser partout. (mais ça donnera l'impression que vous ne maîtrisez pas vous allocations.)

Et cela se retrouve dans plusieurs parties de votre code.

1. len: somme des longueurs des strings à concaténer ( ne peut pas être égal à 0 ):

C'est vous qui le dite, pas votre code:

*size = len; /* copie de la valeur de len dans size*/
if(!*size) /*  si size vaut 0,  donc si len vaut 0 ==> if(len==0) */
    *result = /* et si result devait etre lib'er'e d'abord ? */
      calloc(len + 1, sizeof(char)); /* malloc (len+1), donc malloc(1) */

Si en fait, vous vouliez allouer result parce qu'il ne l'était pas ou plus, vérifiez le directement:

if(NULL==result)

Enfin:

valgrind

En fait, memcheck.
Pour avoir plus de précision sur l'origine de la fuite, utilisez --leak-check=full et consorts.

c’est triste 6 ans après les révélations de Snowden…
[SNIP]

https://www.youtube.com/watch?v=bZW5CJ8OWyQ

---

»La mer est dangereuse, même lorsqu'il n'y a pas d'eau d'dans
»quand on creuse la baie du Mont St-Michel, on trouve plein de chapeaux de boy-scouts.

Vous aviez raison pour le calloc… En effet, result peut avoir été alloué au préalable.
voici le code spécifique à concat dans internal:

Je vois toujours un calloc qui ferait office de malloc dans ce code, tout en négligeant de libérer le pointeur précédent au préalable.

• calloc avec une taille d’élément à 1, soit la taille d'un char, c'est un malloc.

Et il existait (existe?) d'autres calloc douteux que celui de cette fonction.

*size = len;
if(!*size)
    *result = calloc(len + 1, sizeof(char));

Dans cette branche, len vaut 0 quoi qu'il arrive non ?
Donc, c'est équivalent à malloc(1) ?

Je suis tombé sur un truc intéressant intitulé "Communication classique entre processus"
concernant une "possibilité rarement proposée par les shell".

Et, de quoi s'agit-il ?

Alors je sais que c'est un peu imbuvable question longueur,

Oui. Essayez de garder le même style. Ici, la position des {, par exemple, est aléatoire.

utilisez des goto pour la gestion d'erreur avec libération de ressources, ce sera plus lisible et vous risquerez moins d'en oublier une.

Alors mon problème, est que je n'arrive pas à libérer les variables concaténées ( d'où l'utilisation qui fonctionne dans le programme "test.c" ci-dessus ) lorsqu'il s'agit de simples caractères au niveau de l'appel à "process_datas_init" dans "process_exec".

Préférez strncat et strncpy qui vous éviterons des ennuis, d'autant que vous recalculez la longueur juste avant.

Je sens un problème dans process_datas_internal.

Je suppose que result a été alloué ailleurs et passé en paramètre. Dans ce cas, à quoi rime le calloc ? Il provoque une nouvelle allocation de result sans que l'ancien ne soit libéré et n'a pas de sens avec une taille de 1 (sizeof(char)) . Ce n'est pas plutôt un realloc que vous vouliez faire ?

Au passage, plutôt que de faire des if dans les for sur la variable de loop. Traitez les séparément:

/* l=1*/
strcpy(*result, p->commands[i][1]);
/* l=2.. */
for(int l=2;l < p->args[i][1] - 1; l++){
                strcat(*result, p->commands[i][l]);
}

Pourquoi passer size par référence alors que vous ne l'utilisez que par variable ?

Itou.

Ce qui est dommage, c'est que ces deux architectures pourraient se faire concurrence.
D'autant que sous linux, le PowerPC est déjà bien pris en charge.

On peut imaginer qu'il suffirait de ré-activer openfirmware pour obtenir une abstraction matérielle qui tiennent la route.
Ainsi, linux pourrait fournir (enfin) des noyaux plus génériques pour des SOC basés sur cette architecture.

D'autant qu'il me semble que ceux-ci n'étaient pas allergique au bus PCI…

De nos jours, qui entend encore parler de POWER pour de la vente de masse

Dans le monde des SOC et de l'embarqué ? Si cette architecture ne faisaient pas le poids face à ARM, son ouverture peut renverser la tendance.

D'autant qu'il existe une fondation pour le soutenir.
D'ailleurs, l'annonce initiale vient de là:
https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/

Bon, quelques POWER dans le top500 des supercomputers certes
(avec bémol que la puissance est surtout du côté des GPU)

Oui, comme quasiment tous les supercomputer, quelque soit l'architecture du «cœur», non ?