alf a écrit 255 commentaires

En plus de ce qui a déjà été dit (et que j'approuve), je te conseille d'éditer ton code avec un éditeur qui favorise l'indentation automatique... (ou au moins indent pour harmoniser le style sur tous tes fichiers C) :

/* includes... */
int main (int argc, char *argv[])
{
    /* definitions des variables... */
    for (i = 0; i < argc; i++)
    {
        d = open(argv[i], O_RDONLY);
        if (d == -1)
        {
            printf("these file does not exist check the name\n");
            exit(1);
        }
        else
            byte_lu = read(d, tampon, 1024);
        while (byte_lu > 0)
        {
            fd = write(d, tampon, 1024);
        }
        printf("%s", tampon[i]);
    }
    close (d);
}

Tu ne remarques rien d'anormal ? (un indice est dans le titre)

- N'oublie pas de return 0 a la fin de ton int main()

Pour être plus précis, le return 0; n'est pas obligatoire pour sortir de main en C99, mais c'est une pratique chaudement recommendée quand même ;) (voire return EXIT_SUCCESS;, macro définie dans stdlib.h).

En passant, je préfère exit (EXIT_FAILURE); à exit(1); (EXIT_FAILURE étant défini dans le même en-tête).

Pour le 2a), j'ai bien dit que ça pouvait ne pas marcher. D'ailleurs, en C, les casts sont rarement bon signe (sauf cas rares comme en passage de paramètres à des fonctions à nombres de paramètres variables).

Suivant la taille du machin, la correction (le 2b) du code pour le faire fonctionner en environnement C90 (ou même C99) peut être une opération lourde, je n'en doute pas. A toi de voir, suivant le temps dont du dispose, sur qui tu peux taper (ceux qui ont créé l'appli sont toujours dispo ?)...

Je n'avais pas vu avant de poster... "s'adonner", j'approuve. Par contre, "votre putain de faute", je trouve un peu fort par rapport à "your damn fault". Ou alors je me trompe sur le niveau de grossièreté de "damn"... Dans l'autre sens, je crois que "arrêter de mal vous comporter" est un peu faible par rapport à "fix your evil ways".

Mais bon, on ne va pas trop chipoter sur un tirade pareille non plus ;)

"to rest easy" -> "rester calme", "ne pas s'énerver". Enfin, "Don't panic", quoi...
"unspeakable" -> je tenterais bien un "innomables".
Pareil pour "evil", "diabolique" me semble un peu fort. "Devil" siginifie le diable, mais "evil" est plus "mauvais", "malsain"...

D'où ma proposition, en reformulant un petit peu :

C'est un des ces rares noyaux "parfaits". Donc, s'il n'arrive pas à compiler avec votre config (ou s'il compile, mais qu'ensuite il procède à des actes de perversion innomables sur votre teckel), vous pouvez restez calme, en sachant que c'est entièrement votre faute, et que vous devriez juste corriger vos comportements malsains.

Il y a juste le "d*mn" que je ne sais pas encore comment formuler...

Tout marche bien jusqu'a ce que les parametres p1,p2,p3,p5,p6 prennent les valeurs suivantes

p1 = 100, p2 = 1300, p3 = 4000, p5 = 55, p6 = 0

Un tel plantage (segmentation fault lors de la manipulation de pointeurs pointant dans des tableaux) est souvent dû à un débordement des tableaux en question. D'où la question : ces valeurs sont-elles dans les bornes de tes tableaux (ou des espaces mémoire alloués dynamiquement) ?

En passant, en C, pour un tableau de taille N (i.e. dont les indices valides vont de 0 à N-1 inclus), le fait même de calculer l'adresse du pseudo-élément d'indice supérieur à N cause un comportement indéfini (*). Si la même chose est valable en C++ (je n'en sais rien), alors il est possible que tes incrémentations pi += pasi débordent les tableaux, et que cela suffise à causer un plantage.

Plus concrètement : si on suppose
int array[10];
p.mhm=&array[0];
p.mhM = 10;
p.mhs = 3;
Alors, lors de la boucle for (p.p2=p.mhm;p.p2<=p.mhM;p.p2=p.p2+p.mhs) { /* ... */ }, p.p2 prendra les valeurs &array[0], &array[3], &array[6], &array[9] sans problème. Puis, à la fin de la 4e itération, l'incrément affectera la valeur "&array[12]", qui est invalide. En C, le comportement indéfini surviendrait ici, et se manifesterait probablement par un segmentation fault sur ton système.

A toi de voir si ton code permet d'être dans une telle situation, et si le comportement indéfini s'applique aussi en C++.

(*) Le calcul de l'adresse du pseudo-élément d'indice N est par contre bien défini, c'est une exception tolérée pour faciliter les traitements de tableaux par pointeurs. Par contre, essayer d'accéder (en lecture ou en écriture) au contenu de ce pseudo-élément (qui n'existe pas) cause un comportement indéfini. Tout ceci est valable en C, je le rappelle ; je ne sais pas si ça concerne aussi le C++.

Et si tu affiches directement stats.st_gid, et stats.st_uid, avant l'appel de getgr[ug]id, ce sont bien les bonnes valeurs ?

Ca ne corrigera probablement pas ce problème précis, mais il faut aussi rajouter des tests d'erreur pour stat, getgrid, etc.

Surtout que "divtateur bienveillant" (ou "benevolent dictator") est une expression assez courante dans le monde du logiciel libre. Je l'ai déjà lue à propos de Théo de Raadt et Linus Torvalds... Il me semble de plus qu'ils l'ont revendiquée pour eux-mêmes lors d'interviews, mais j'ai la flemme de chercher. Peut-être sur kerneltrap ou lwn...

Cela dit, pour ceux qui ne connaissant pas le folklore, un petit lien dans la news vers l'article français de Wikipedia n'aurait pas fait de mal. Si une personne qui a mal compris la chose a pris la peine de faire un message pour le dire, il doit bien en avoir qui n'ont pas compris non plus, et qui repartiront sur une impression que linuxfr dénigre Mark Shuttleworth, sans se donner la peine de laisser des messages.

Muf... C'est pas spécifié dans POSIX, le comportement de echo ? Faudrait vérifier dans les man, ou dans les Single Unix Specification (qui sont un sur-ensemble de POSIX, et surtout qui ont l'avantage d'être disponible en libre téléchargement).

Un fichier source avec l'extension cpp, et un include sans ".h", c'est le signe d'un programme C++. Dans ce cas, il ne faut pas le compiler avec gcc mais g++. Pour le reste, je suis d'accord, l'option -I ("i majuscule") est à utiliser à la compilation pour ajouter le bon dossier où sont déposés les fichiers d'include.

Par contre, la documentation de la bibliothèque (ou au moins les messages de configure) devrait indiquer dans quel dossier sont placés les fichiers d'include.

Tu as deux solutions:

1) trouver un compilo K&R. La portabilité serait minimale, et la mintenance douteuse. de plus, ça te prive des avancés du C depuis près d'une vingtaine d'années (1989, quand même)...

2) corriger le code. Ca peut se faire de 2 façons:
a) des casts pour faire taire le compilateur. C'est très rarement une bonne idée, car ça cache des comportements plus ou moins indéfinis, ce qui veut dire que ça peut ne pas marcher (enfin, ça cache les warnings, mais ça ne garantit pas que ton appli marche bien après).

b) ou remplacer les char * par des void * à chaque fois que c'est possible. C'est la solution que je préfère. Par exemple, dans mon post précédent, il faudrait simplement ne pas passer par une variable temporaire char *p1 et affecter directement le retour de malloc dans p2, ou changer la déclaration du type de p1 de char * en void *.

Mais une telle modification doit être faite avec attention, car il faut distinguer les cas où on a vraiment besoin du type char, pour traiter des chaînes de caractères, et où il est utilisé comme type "générique" (ce pour quoi le type void a été créé).

Bref, bon courage.

void aff(unsigned int adr, int sz)
/* .... */
int main(void)
{
int t1;
short t2;
long t3;
long long t4;
char t5;

aff((unsigned long)&t1,sizeof(int));
aff((unsigned long)&t2,sizeof(short));
aff((unsigned long)&t3,sizeof(long));
aff((unsigned long)&t4,sizeof(long long));
aff((unsigned long)&t5,sizeof(char));
return 0;
};

Un cast d'un pointeur vers un type unsigned long n'est pas garanti par la norme, il peut y avoir des pertes. Par contre, le type uintptr_t (si je ne m'abuse, vérifie dans la norme) est fait pour convertir sans perte (ou avec le minimum de perte ?) une valeur entre les type pointeur et entier.

De plus, tu castes en unsigned long, alors que ta fonction attend un unsigned int...?

Par ailleurs, sizeof renvoie un size_t, et je ne croie pas que ce type ait forcément un domaine de valeurs inclut dans celui de int. Il pourraît être plus grand, si par exemple int fait 32 bits et qu'on peut allouer des objets dont la taille est plus grosse que 2^32 bits.

Ok, tu n'as montré ici qu'un code "juste pour tester", pas l'appli complète. Mais en te faisant les remarques ici, ça pourra peut-être éviter que les mêmes choses arrivent dans l'appli...

Pour compléter mon post juste au-dessus, je ne dis pas que connaître l'adressage et alignement mémoire n'est pas nécessaire dans ton cas, mais juste que, si tu peux arriver à coder ce que tu veux sans avoir à faire ce genre de tests, c'est plus sûr (et plus portable). Mais tu dois déjà être au courant...

De toute façon pour du code portable, on s'en fiche un peu.

J'approuve.

On sait que l'on a sizeof(int) <= sizeof(long) <= sizeof(long long),

Faux. On a "rangeof(int) <= rangeof(long) <= rangeof(long long)" où rangeof désigne le domaine de valeurs couverts par le type (et même "rangeof(char) <= rangeof(short) <= rangeof(int)").
Vicisieusement, la norme C ne spécifie rien sur les tailles des types entiers, si ce n'est que sizeof(char) == 1, et que sizeof(T) doit toujours renvoyer une valeur de type size_t (donc des valeurs entières, et pas 0,5 ou 2,75 par exemple).

Bon, après, en pratique, il ne doit y avoir qu'une DS9k pour avoir sizeof(int) > sizeof(long). Mais elle en a le droit, merci les bits de bourrage ;)

et que comme peu d'architectures apprécient les accès non alignés, qu'une variable de type long est forcément alignée à une adresse multiple de sizeof(long). Pas la peine de se coltiner des #define ou des valeurs magiques.

Idem aussi. Tant qu'on s'amuse avec les pointeurs et sizeof dans les limites de la norme, on s'en fiche de savoir si long est aligné sur 4 ou 8 octets...

Le cast est inutile, et ton exemple n'est pas approprié. Si la libc de son système déclare *alloc comme retournant des valeurs de type void * (ce qui est correct en mode C90 et plus), alors le code:

size_t n = /* untruc */ ;
char * toto = malloc(n);

marche très bien quand il est compilé en mode C90 ou plus (car la conversion implicite void * => char * est définie).

Par ailleurs, note que sizeof(char) vaut toujours 1, par définition, et donc qu'on peut l'oublier dans l'écriture de l'argument à *alloc() (sauf si on veut insister explicitement).

Le problème, c'est que le malloc du C K&R renvoie une valeur de type char *, et donc que, quand on avait besoin d'une valeur de type T*, où T est un type incompatible avec char (come un int, une structure, ou un truc bizarre), alors on pouvait écrire du code comme

char *p1 = malloc(n * sizeof T);
T *p2 = p1;

ce qui était valide en C K&R, car la conversion implicite d'une valeur de type char * en tout autre type T * était définie (si je ne m'abuse), mais cette conversion cause un comportement indéfini en C90 (ou au mieux implementation-defined). A ma connaissance, gcc ne supporte *pas* de mode K&R, mais tolère juste certaines notations K&R quand on compile en mode "extentsion Gnu", donc un tel code risque de toujours lever des warnings dans gcc.

Par aileurs, sans voir le code qui pose problème, il est difficile d'apporter une vraie solution au problème... Peut-être (et même probablement) est-il nécessaire de changer le code mais, sans le voir, c'est difficile à dire...

Pas la peine de définir ses constantes en double: en l'absence de prototype, les valeurs des arguments de type float sont convertis en valeurs de type double avant l'appel d'une fonction. Reste que printf() est définie avec un type variable, donc j'ai un doute sur le statut exact. Reste que, à 99% de chances, la conversion des arguments float en double est effectuée.
Pour les autres cas, dans son code, les constantes 0.5 et autres sont de type double, donc le produit aussi, donc il n'y a aucun problème de typage dans son code (à part le fait que main renvoie un int).

if(n != 0) {
text = realloc(text, (sizeof(char*)*(n+1))); }

ptr = strchr(line, '\n');
*ptr = '\0';
text[n] = malloc(sizeof(char*)*strlen(line)+1);
strcpy(text[n], line);
n++;
}

Vu le coût d'un realloc(), il vaut mieux l'utiliser pour doubler la taille du tableau à chaque appel (pseudo-code non testé) :

size_t capacity = 1;
size_t n = 0;
char **text = malloc (capacity * sizeof(char*));
char *ligne = NULL;
if (text == NULL)
{
    return NULL;
}
while (lire_ligne(ligne, file) != NULL)
{
     if (n == capacity)
    {
        char **tmp = NULL;
        capacity *= 2;
        tmp = realloc(text, capacity * sizeof(char*));
        if (tmp == NULL)
        {
            /* free(text) et tout ce qui précède */
            return NULL;
        }
        text = tmp;
    }
    text[n] = ligne;
    n++;
}

Où la fonction lire_ligne est un wrapper autour de fgets() qui ne tronque pas les lignes (cf. https://linuxfr.org/comments/713347.html#713347 pour un de mes messages à ce sujet). De plus, comme dans mon pseudo-code, il faut tester le retour de realloc(), pour éviter les fuites de mémoire.

En avant-propos, merci de ces propos intéressants ;)

Concernant tes remarques, et celles de Charlax, sur le profit, ça m'a fait penser à ce que j'ai lu récemment dans The future does not compute de Steve Talbott [1]. Dans ce livre (que je conseille absolument, c'est une vraie mine d'or), l'auteur évoque l'entreprise moderne comme une "machine qui fonctionne toute seule" ("a machine that runs by itself" est son expression). En, particulier, dans le chapitre 3, The Future Does Not Compute, il dit:

What has fallen out of this picture? Just the entire meaning of work, just the whole human reason why people band together and direct their creative energies toward productive ends. Ends -- things worth pursuing. Goods that are good, services that serve. The corporation has divorced itself from questions like "What task do I wish to take up in the world?" and "What is the future we wish to create?" We form our companies only to learn that they no longer embody our ends, but somehow have a neat, predictable logic of their own. We choose a future only to find it taken out of our hands, exchanged for a permutation of the past.

et, dans le chapitre 8, Things That Run by Themselves :

The aim of the entire effort is no longer a good or service, the achievement of which requires, among other things, economic discipline; rather, the economic "bottom line" itself becomes the controlling focus of the company. But this is to turn things upside down and inside out. It leads to episodes like the one James O'Toole reports:

I once asked a PepsiCo vice president if anyone in that corporation had ever raised the issue of the morality of promoting junk food in ghetto areas where kids weren't getting enough basic foods. He answered, "If anyone would ever be so foolish as to raise the question, he'd find himself out on the street." /1/

Needless to say, employees sense this reversal of ends and means, this loss of human purpose, and come to see the company as competing against their own goals and interests. To ask, why am I doing this work? -- what human vision of the future are we as a company striving to realize? -- is hereafter to sound a rather uncomfortable, dissonant note within the organization. It is easier to say, "I just work here," and to seek one's deeper satisfactions elsewhere.

Il me semble que ces deux extraits sont appropriés: le reproche fait aux entreprises modernes n'est pas de vouloir faire du profit (enfin, mis à part quelques extrémistes), mais d'être orienté vers le seul profit, et d'avoir oublié qu'une entreprise doit avant tout produire quelque chose, qui aura des utilisateur (que ce soit une voiture, un logiciel, un grille-pain, un contrat d'assurance, etc.). Le principe de libre concurrence [2] fait que les entreprises qui proposent les meilleurs services/produits, i.e. ceux qui répondent le mieux aux besoins des clients, auront le plus de clients, et donc de profit [3]. Dans cette vue (que certains aujourd'hui disent utopiste), le but de l'entreprise est double: 1) satisfaire son client, afin de faire du "profit", ce profit servant à 2) faire vivre les personnes qui forment l'entreprise.

Ce que Steve Talbott a mis en lumière (et sûrement d'autres, je suppose, mais c'est dans ses écrits que je l'ai vu le mieux expliqué), c'est que l'entreprise moderne "fonctionne toute seule", avec sa propre logique, ses propres buts, qui ne sont plus ceux de ses employés - ni même de ses patrons ! C'est juste une machine à faire de l'argent, qui grossit sans limites, et pour laquelle le client n'est plus qu'un moyen d'atteindre son objectif (dans un tel contexte, rendre son client "captif" est une stratégie valable... ).


J'aurais une remarque sur ta phrase:

Si les miliardaires font des don[s] c'est pour se racheter, pour rentrer dans u[n]e logique catholique de rachat de ces péchés.

Je me trompe peut-être dans le cas particulier des individus dont tu parles, mais ils vivent (il me semble) dans des pays plus protestants que catholiques. Mais c'est juste une remarque en passant.

Sur ta phrase:

Par exemple tu pense que le libéralisme c'est la libre diffusion des connaissances et des biens, c'est une grosse méprise. Tout se paye dans le libéralisme. Je vois mal un systéme libérale ou on ne paye pas ces oranges. Je trouve que tu confond plus avec un systéme libertaire.

Je peux me tromper sur ce que charlax a voulu dire, mais libre != gratuit ;) Il n'y a rien de contradictoire (selon moi, mais j'ai pu ne pas voir certaines choses) entre la libre circulation des biens et le fait que le "client final"/consommateur devra payer le bien pour en profiter.

[1] http://natureinstitute.org/txt/st/details/fdnc.htm
[2] Ce principe me semble être une des bases du libéralisme, au contraire de certaines théories modernes (ce qui est appelé "néo-libéralisme", ou "ultra-libéralisme" je crois. Enfin bref.) qui se satisfont des monopoles et pratiques anti-concurrentielles; mais j'admets que la notion de "libéralisme" est assez floue parfois.
[3] Ok, le lien "plus de client donc plus de profit" est spécieux, je néglige ici les questions de marge bénéficiaire, tout ça tout ça.

Pour moi, Ramon Perez, c'est plutôt une chanson des VRP ;) (t'arrives à dormir ?)

il n'y a pas d'erreur dans ta requete
c'est la version de Mysql qui n'accepte des select imbriqué

Jusqu'à la version 4.0, il me semble, la 4.1 implémentant (enfin !) les requêtes imbriquées (appelées aussi sous-requêtes).

Par contre, ce n'est pas une erreur de syntaxe, mais je suggère très fortement de mettre des alias quand des tables ou des colonnes apparaissent plusieurs fois dans une même requête:

SELECT DISTINCT A.NUMAPPEL
FROM APPEL A
WHERE A.NUMAPPEL NOT IN (SELECT D.NUMAPPEL FROM DETAIL D);

Comme dit plus haut, il faut [...]

Non. "On peut" faire ainsi. Mais, en SQL, il y a souvent bien plus d'une façon de le faire... J'en ai donné une au-dessous, mais je pense qu'une solution basée sur une division relationnelle est aussi possible (juste une idée comme ça, je n'ai pas cherché comment la faire).

Une idée qui me vient, par forcément optimisée: on recherche d'abord les immeubles qui n'ont qu'un propriétaire:

SELECT   B.ADRESSE
FROM     APPARTEMENT B
GROUP BY B.ADRESSE
HAVING   COUNT(B.PROPRIO) = 1

Puis on détermine les noms des propriétaires de ces immeubles:

SELECT DISTINCT P.NOM
FROM   PERSONNE P
       JOIN APPARTEMENT A
           ON P.NOM=A.PROPRIO
WHERE  A.ADRESSE in (SELECT B.ADRESSE
                     FROM APPARTEMENT B
                     GROUP BY B.ADRESSE
                     HAVING COUNT(B.PROPRIO) = 1)

En fait, cette requête détermine les noms des propriétaires de chaque appartement dont l'adresse est celle d'un immeuble n'ayant qu'un propriétaire, puis on fait un "DISTINCT" sur cette liste. (devant traiter au quotidien des requêtes infâmes faisant des jointures à plus de 10 tables, je suis assez pointilleux sur l'indentation de mon SQL ;)

Pour tout ce qui est configure / autotools, la doc GNU est la référence (et de très bonne qualité) http://sources.redhat.com/automake/automake.html (et aussi http://linuxfr.org/forums/19/16194.html pour une question sur ce même point)

Une bonne règle pour le makefile: pas de récursivité !
http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-har(...) (le titre de l'article est "inspiré" du célèbre article "goto considered harmful" de Dijkstra ( http://www.acm.org/classics/oct95/ ). Autant pour Dijkstra j'avais lu que c'est l'éditeur qui avait choisi le titre, autant pour Miller je ne sais pas. Enfin, c'est de l'ordre du détail.).

Pour faire du GPL: déjà, lire la GPL pour savoir ce que c'est. http://www.gnu.org/copyleft/gpl.html pour la version originale, http://fsffrance.org/gpl/gpl-fr.fr.html pour une traduction non officielle (par contre, le lien ne marche pas... fsffrance.org est indisponible ? Ou je dois mettre à jour mes liens ?)

C'est marrant comme, même toi, tu es terriblement conditionnée par les clichés alors que pourtant tu le sais que ce ne sont que des clichés... En quoi "être meilleur dans les matières scientifiques que litéraires" est-il un attribut masculin ?

Elle pourra mieux te répondre que moi sur ce point, mais j'ai compris sa phrase

Et puis, non, franchment, je suis pas une fille qui rentre dans la "norme féminine"

comme justement une liste de préjugés sexistes dont elle a conscience mais auxquels elle ne correspond pas.

En tout cas, je suis capable de te citer des contre-exemples dans les deux sens pour tous ces critères.

Elle t'en a déjà donné un valable dans un sens : elle-même !

Pas de bol, je ne fais pas de VB (enfin, pas depuis un bon moment...), par contre j'utilise au boulot un autre langage qui se sert de <> pour faire les tests d'inégalité.

Gni ? Je dis juste que geek <> gros lourd. Après, si t'interprète ça comme de la drague...